Créer et accorder l'accès à des ressources confidentielles

Les collaborateurs de données doivent configurer les ressources suivantes pour que leurs données confidentielles soient accessibles par une charge de travail :

  • Données chiffrées stockées dans Google Cloud.

  • Un pool d'identités de charge de travail (WIP, workload identity pool) pour autoriser la charge de travail. Une fois qu'une charge de travail a été autorisée par un pool d'identités de charge de travail, elle peut accéder aux données confidentielles des collaborateurs et les traiter.

De plus, les collaborateurs de données doivent choisir où stocker les résultats de la charge de travail Confidential Space et indiquer si ces résultats sont propres à chaque collaborateur ou partagés. Par exemple, vous pouvez choisir d'envoyer le même résultat à plusieurs buckets Cloud Storage appartenant à chaque collaborateur de données.

Stocker vos données chiffrées

Vous pouvez utiliser n'importe quel service Google Cloud stockant des données pour héberger vos données confidentielles. Par exemple, vous pouvez utiliser l'un des services suivants :

Vous devez vous assurer que ces données sont chiffrées au repos, que ce soit à l'aide de fonctionnalités intégrées ou d'un service tel que Cloud Key Management Service (Cloud KMS).

Autoriser la charge de travail avec un pool d'identités de charge de travail

Un WIP est le mécanisme utilisé par Confidential Space pour permettre à une charge de travail externe d'accéder à vos données confidentielles et de les utiliser en tant qu'identité fédérée. Une identité fédérée est une entité externe traitée comme un compte principal dans votre propre projet. Vous pouvez lui attribuer des rôles IAM pour lui donner accès à des ressources spécifiques ou lui permettre d'emprunter l'identité de comptes de service pour faire de même.

En tant que collaborateur de données, vous configurez un fournisseur dans un pool d'identités de charge de travail qui définit les règles pour les entités s'authentifiant en tant qu'identité fédérée. Pour Confidential Space, vous devez définir les éléments suivants dans un fournisseur :

  • Service d'attestation : ce service vérifie que la charge de travail est une instance de VM confidentielle et renvoie un jeton d'attestation OpenID Connect (OIDC) au fournisseur WIP. L'opérateur de charge de travail définit le service d'attestation utilisé. Il doit correspondre au service d'attestation ajouté au fournisseur de pool d'identités de charge de travail pour que l'accès soit accordé.

  • Mappages d'attributs : attributs des jetons d'accès Security Token Service mappés aux assertions effectuées par l'entité d'authentification (dans le cas présent, l'instance de VM qui exécute la charge de travail). Les assertions sont effectuées par l'instance de VM elle-même, l'image Confidential Space et le conteneur de charge de travail, puis transmises au fournisseur WIP par la charge de travail. Ces attributs sont utilisés pour des éléments tels que les journaux d'audit dans Cloud Logging et pour accorder des rôles via IAM sur la base des assertions d'entité d'authentification, telles que les digests de conteneur d'image de charge de travail. En savoir plus sur les mappages d'attributs

  • Une règle d'attestation : série de conditions que les entités qui s'authentifient doivent remplir pour obtenir l'accès, en fonction des assertions qu'elles font.

Lorsqu'une charge de travail démarre, le lanceur Confidential Space envoie son rapport d'attestation à un service d'attestation défini par l'opérateur de charge de travail, qui vérifie l'instance de VM confidentielle, puis renvoie un jeton d'attestation OIDC. Ce jeton dure une heure et est automatiquement actualisé.

Le jeton d'attestation est ensuite transmis au fournisseur WIP par la charge de travail. Le fournisseur l'utilise pour vérifier que les assertions respectent la règle d'attestation définie dans le fournisseur. Si tel est le cas, la charge de travail est autorisée à accéder aux ressources confidentielles.

Accès aux charges de travail externes

Avant de configurer un pool d'identités de charge de travail et un fournisseur, vous devez choisir comment la charge de travail va accéder à vos ressources : accès direct aux ressources ou emprunt d'identité d'un compte de service.

Accès direct aux ressources

Nous recommandons la méthode d'accès direct aux ressources pour les charges de travail.

Cette méthode consiste à configurer une identité fédérée dans un fournisseur WIP associé aux assertions d'une entité d'authentification. De cette façon, une charge de travail peut être autorisée à accéder directement aux ressources via des liaisons IAM, en fonction d'attributs tels que le condensé de l'image de conteneur de la charge de travail.

L'accès direct aux ressources présente les avantages suivants :

  • La configuration d'un environnement Confidential Space nécessite moins d'étapes, car les collaborateurs de données n'ont pas besoin de configurer de comptes de service pour qu'un compte de service de charge de travail emprunte leur identité.

  • La charge de travail n'est autorisée à accéder qu'à des ressources spécifiques, comme déterminé par IAM. Cette méthode est plus sécurisée que l'emprunt d'identité d'un compte de service, où des comptes de service disposant d'autorisations excessives ou des droits d'emprunt d'identité peuvent donner à un utilisateur malintentionné un accès plus étendu que prévu.

  • Chaque accès aux ressources est consigné avec l'identité fédérée d'une instance de VM de charge de travail, au lieu de l'identité d'un compte de service dont l'identité peut être empruntée et qui peut être partagé par plusieurs charges de travail. L'identité d'une instance de VM de charge de travail peut inclure des détails tels que le condensé de l'image d'un conteneur, le numéro de projet à partir duquel la charge de travail fonctionne et l'ID de l'instance de VM exécutant la charge de travail, ce qui fournit un journal d'audit plus détaillé.

  • Vous n'avez pas besoin de mapper la propriété selfLink de l'instance de VM à l'attribut google.subject dans un fournisseur WIP. Les valeurs selfLink très longues peuvent dépasser la limite de 127 octets de cet attribut, ce qui entraîne l'échec de l'authentification du fournisseur WIP.

Emprunter l'identité d'un compte de service

La méthode d'emprunt d'identité de compte de service implique que chaque collaborateur de données configure un compte de service pour déchiffrer ses données privées, puis associe ce compte de service à son propre pool d'identités de charge de travail. Ils spécifient également le compte de service de charge de travail dans leur fournisseur WIP, ce qui permet au compte de service de charge de travail d'emprunter l'identité des comptes de service des collaborateurs de données afin de pouvoir récupérer et traiter leurs données confidentielles.

L'emprunt d'identité d'un compte de service ne doit être utilisé que dans les cas suivants :

Il est possible que la méthode d'emprunt d'identité du compte de service ne parvienne pas à s'authentifier auprès d'un fournisseur WIP si une instance de VM possède une propriété selfLink très longue. En effet, la revendication sub du jeton d'attestation, qui est définie sur la valeur selfLink, est mappée dans le fournisseur WIP à l'attribut google.subject, qui est limité à 127 octets.

Pour les valeurs selfLink d'instance de VM qui dépassent 127 octets, vous devez renommer vos instances de VM pour raccourcir le selfLink ou utiliser la méthode d'accès direct aux ressources.

Configurer un pool d'identités de charge de travail et un fournisseur

La procédure de configuration d'un fournisseur varie selon que vous utilisez l'accès direct aux ressources ou l'emprunt d'identité d'un compte de service.

Accès direct aux ressources

La méthode d'accès direct aux ressources consiste à configurer un pool d'identités de charge de travail et un fournisseur, puis à configurer des rôles IAM en fonction d'un condensé d'image de conteneur de charge de travail spécifique.

Configurer un pool d'identités de charge de travail et un fournisseur

Pour configurer un pool d'identités de charge de travail et un fournisseur, suivez les instructions ci-dessous :

  1. Créez le WIP :

    gcloud iam workload-identity-pools create DATA_COLLABORATOR_POOL_NAME \
    --location=global

  2. Créez un fournisseur OIDC dans le pool d'identités de charge de travail :

    gcloud iam workload-identity-pools providers create-oidc attestation-verifier \
    --location=global \
    --workload-identity-pool=DATA_COLLABORATOR_POOL_NAME \
    --issuer-uri="https://confidentialcomputing.googleapis.com/" \
    --allowed-audiences="https://sts.googleapis.com" \
    --attribute-mapping="google.subject=\"gcpcs::\"+assertion.submods.container.image_digest+\"::\"+assertion.submods.gce.project_number+\"::\"+assertion.submods.gce.instance_id,attribute.image_digest=assertion.submods.container.image_digest" \
    --attribute-condition="assertion.swname == 'CONFIDENTIAL_SPACE' \
        && 'STABLE' in assertion.submods.confidential_space.support_attributes"

    Cet exemple utilise les valeurs suivantes :

    • issuer-uri sur https://confidentialcomputing.googleapis.com/, ce qui signifie que Google Cloud Attestation est utilisé comme service d'attestation.

    • allowed-audiences sur https://sts.googleapis.com. Il s'agit du service de jetons de sécurité de Google, qui échange des identifiants contre des jetons d'accès.

    • Un attribute-mapping de google.subject, avec la valeur suivante :

      \"gcpcs::\"+assertion.submods.container.image_digest+\"::\"+assertion.submods.gce.project_number+\"::\"+assertion.submods.gce.instance_id,attribute.image_digest=assertion.submods.container.image_digest

      Cette valeur est construite à l'aide du CEL (Common Expression Language). Les valeurs suivantes sont attribuées à l'attribut gcpcs et s'affichent dans Cloud Logging chaque fois que la charge de travail accède à des ressources :

      • assertion.submods.container.image_digest : condensé de l'image du conteneur de charge de travail.

      • assertion.submods.gce.project_number : numéro de projet de l'instance de VM.

      • assertion.submods.gce.instance_id : ID de l'instance de VM.

      De plus, attribute.image_digest est défini sur assertion.submods.container.image_digest, le condensé de l'image du conteneur de charge de travail. Cet attribut est mappé pour vous permettre d'accorder des rôles IAM à l'identité fédérée en fonction d'un condensé d'image spécifique.

      Vous pouvez mapper n'importe quelle assertion de charge de travail disponible, à condition que la longueur totale de la valeur google.subject soit inférieure à 127 octets.

    • Les attribute-conditions suivants, qui constituent une règle d'attestation. Si ces conditions correspondent aux assertions de la charge de travail, celle-ci est autorisée à accéder aux ressources confidentielles en tant qu'identité fédérée :

      • assertion.swname == 'CONFIDENTIAL_SPACE' : vérifie que Confidential Space est le logiciel exécuté sur la VM, avec toutes ses garanties de sécurité intégrées.

      • 'STABLE' in assertion.submods.confidential_space.support_attributes : vérifie que l'image de production Confidential Space est utilisée et qu'elle possède l'attribut de compatibilité STABLE.

      Pour découvrir d'autres conditions d'attributs que vous pouvez utiliser, consultez Créer une règle d'attestation.

Accorder les rôles IAM à l'identité fédérée

Une fois que vous avez créé un fournisseur de pool d'identités de charge de travail, vous pouvez accorder à l'identité fédérée un rôle IAM en fonction de la correspondance entre le résumé du conteneur d'image de charge de travail de l'identité et une valeur attendue.

L'exemple suivant montre comment accorder à une identité fédérée la possibilité de déchiffrer une clé Cloud Key Management Service spécifique :

gcloud kms keys add-iam-policy-binding \
    projects/DATA_COLLABORATOR_PROJECT_ID/locations/global/keyRings/DATA_COLLABORATOR_KEYRING_NAME/cryptoKeys/DATA_COLLABORATOR_KEY_NAME \
    --member="principalSet://iam.googleapis.com/projects/DATA_COLLABORATOR_PROJECT_NUMBER/locations/global/workloadIdentityPools/DATA_COLLABORATOR_POOL_NAME/attribute.image_digest/WORKLOAD_CONTAINER_IMAGE_DIGEST" \
    --role=roles/cloudkms.cryptoKeyDecrypter

Emprunter l'identité d'un compte de service

La méthode d'emprunt d'identité de compte de service implique les éléments suivants :

  1. Créez des comptes de service dans chacun des projets de collaborateurs de données, puis accordez-leur l'autorisation de déchiffrer les données confidentielles.

  2. Créez des pools d'identités de charge de travail dans chacun des projets de collaborateurs de données, puis associez le compte de service de chaque projet qui vient d'être créé à son pool d'identités de charge de travail.

  3. Créez des fournisseurs d'identité de charge de travail dans chaque pool d'identités de charge de travail, en spécifiant le compte de service de charge de travail comme compte autorisé à emprunter l'identité des comptes de service de collaborateurs de données.

Configurer des comptes de service pour déchiffrer les données confidentielles

  1. Créez les comptes de service dans les projets de collaborateurs de données :

    gcloud iam service-accounts create DATA_COLLABORATOR_SERVICE_ACCOUNT_NAME

    Accordez aux comptes de service les autorisations nécessaires pour déchiffrer les données confidentielles. Par exemple, vous pouvez chiffrer des fichiers confidentiels dans Cloud Storage avec Cloud KMS. Vous devez donc accorder au compte de service l'autorisation de déchiffrer ces données :

    gcloud kms keys add-iam-policy-binding \
    projects/DATA_COLLABORATOR_PROJECT_ID/locations/global/keyRings/DATA_COLLABORATOR_KEYRING_NAME/cryptoKeys/DATA_COLLABORATOR_KEY_NAME \
    --member=serviceAccount:DATA_COLLABORATOR_SERVICE_ACCOUNT_NAME@DATA_COLLABORATOR_PROJECT_ID.iam.gserviceaccount.com \
    --role=roles/cloudkms.cryptoKeyDecrypter

Configurer un pool d'identités de charge de travail et un fournisseur

Pour configurer un fournisseur et un WIP, suivez les instructions ci-dessous dans chaque projet de collaborateur de données :

  1. Créez le WIP :

    gcloud iam workload-identity-pools create DATA_COLLABORATOR_POOL_NAME \
    --location=global

  2. Associez le compte de service qui sera utilisé pour l'usurpation d'identité au pool d'identités de charge de travail, avec le rôle roles/iam.workloadIdentityUser :

    gcloud iam service-accounts add-iam-policy-binding \
    DATA_COLLABORATOR_SERVICE_ACCOUNT_NAME@DATA_COLLABORATOR_PROJECT_ID.iam.gserviceaccount.com \
    --member="principalSet://iam.googleapis.com/projects/DATA_COLLABORATOR_PROJECT_NUMBER/locations/global/workloadIdentityPools/DATA_COLLABORATOR_POOL_NAME/*" \
    --role=roles/iam.workloadIdentityUser

  3. Créez un fournisseur OIDC dans le pool d'identités de charge de travail et définissez-y le compte de service de charge de travail afin qu'il puisse emprunter l'identité du compte de service du collaborateur de données :

    gcloud iam workload-identity-pools providers create-oidc attestation-verifier \
    --location=global \
    --workload-identity-pool=DATA_COLLABORATOR_POOL_NAME \
    --issuer-uri="https://confidentialcomputing.googleapis.com/" \
    --allowed-audiences="https://sts.googleapis.com" \
    --attribute-mapping="google.subject=assertion.sub" \
    --attribute-condition="assertion.submods.container.image_digest == 'WORKLOAD_CONTAINER_IMAGE_DIGEST' \
&& 'WORKLOAD_SERVICE_ACCOUNT_NAME@WORKLOAD_OPERATOR_PROJECT_ID.iam.gserviceaccount.com' in assertion.google_service_accounts \
&& assertion.swname == 'CONFIDENTIAL_SPACE' \
&& 'STABLE' in assertion.submods.confidential_space.support_attributes"

    Cet exemple utilise les valeurs suivantes :

    • issuer-uri sur https://confidentialcomputing.googleapis.com/, ce qui signifie que Google Cloud Attestation est utilisé comme service d'attestation.

    • allowed-audiences sur https://sts.googleapis.com. Il s'agit du service de jetons de sécurité de Google, qui échange des identifiants contre des jetons d'accès.

    • Un attribute-mapping de google.subject, avec la valeur assertion.sub. Il s'agit de l'selfLink de l'instance de VM, tel que défini dans la revendication sub du jeton d'attestation.

      L'instance de VM selfLink s'affiche dans Cloud Logging chaque fois que la charge de travail accède à des ressources.

    • Les attribute-conditions suivants, qui constituent une règle d'attestation. Si ces conditions correspondent aux assertions de la charge de travail, celle-ci est autorisée à accéder aux ressources en tant qu'identité fédérée :

      • assertion.submods.container.image_digest == 'WORKLOAD_CONTAINER_IMAGE_DIGEST' : vérifie que le condensé de l'image du conteneur de charge de travail correspond à la valeur attendue.

      • 'WORKLOAD_SERVICE_ACCOUNT_NAME@WORKLOAD_PROJECT_ID.iam.gserviceaccount.com' in assertion.google_service_accounts : vérifie que le compte de service associé à la charge de travail correspond au compte de service attendu, puis l'utilise pour emprunter l'identité du compte de service du collaborateur de données.

      • assertion.swname == 'CONFIDENTIAL_SPACE' : vérifie que Confidential Space est le logiciel exécuté sur la VM, avec toutes ses garanties de sécurité intégrées.

      • 'STABLE' in assertion.submods.confidential_space.support_attributes : vérifie que l'image de production Confidential Space est utilisée et qu'elle possède l'attribut de compatibilité STABLE.

      Pour découvrir d'autres conditions d'attributs que vous pouvez utiliser, consultez Créer une règle d'attestation.

Créer une règle d'attestation

Pour créer un pool d'identités de charge de travail, vous devez créer une règle d'attestation. Les assertions d'une entité d'authentification doivent correspondre à votre règle pour pouvoir accéder à vos données.

Les règles sont écrites en Common Expression Language (CEL) et sont constituées d'une série d'instructions pouvant être associées à l'opérateur &&.

Les instructions utilisent des assertions de l'image Confidential Space, de l'image du conteneur de charge de travail ou de l'instance de VM comme variables, et la valeur que vous avez spécifiée comme expression. Par exemple, voici une règle qui impose que la charge de travail utilise Confidential Space, qu'elle doit utiliser une image Confidential Space STABLE et que la zone dans laquelle l'instance de VM de charge de travail s'exécute doit être us-central1-a :

assertion.swname == 'CONFIDENTIAL_SPACE' \
&& 'STABLE' in assertion.submods.confidential_space.support_attributes" \
&& assertion.submods.gce.zone == "us-central1-a"

Pour en savoir plus, consultez Assertions d'attestation.

Assertions d'attestation

Les assertions disponibles pour créer une règle d'attestation sont détaillées dans le tableau suivant. Les règles peuvent valider les assertions faites par l'image Confidential Space, le conteneur de charge de travail et l'instance de VM.

Affirmations concernant les images

Assertion Type Description

assertion.dbgstat

Interagit avec :

 Chaîne définie

Vérifie que l'image Confidential Space est la version de débogage ou de production.

Les valeurs valides sont les suivantes :

  • enable : vérifiez que l'image de débogage est utilisée.
  • disabled-since-boot : vérifiez que l'image de production est utilisée.
Exemples

Le code suivant vérifie que la version de débogage de l'image Confidential Space est utilisée :

assertion.dbgstat == "enable"

Le code suivant vérifie que la version de production de l'image Confidential Space est utilisée :

assertion.dbgstat == "disabled-since-boot"
assertion.submods.confidential_space.support_attributes Tableau de chaînes.

Vérifie que la version de sécurité du TEE est une image Confidential Space de production. Aucun attribut de compatibilité n'est défini pour les images Confidential Space de débogage.

Il existe trois attributs de compatibilité :

  • LATEST : il s'agit de la dernière version de l'image, compatible. L'image LATEST est également STABLE et USABLE.
  • STABLE : cette version de l'image est compatible et surveillée pour détecter les failles. Une image STABLE est également USABLE.
  • USABLE : une image ne contenant que cet attribut n'est plus compatible et n'est plus surveillée pour détecter les failles. L'utilisation de cette solution relève entièrement de votre responsabilité.
  • EXPERIMENTAL : une image ne comportant que cet attribut utilise les fonctionnalités d'aperçu. Elle n'est fournie qu'à des fins de tests et ne doit jamais être utilisée en production. Une image EXPERIMENTAL ne comporte jamais les attributs LATEST, STABLE ni USABLE.
Exemple

Le code suivant vérifie qu'une version stable de l'image Confidential Space est utilisée :

"STABLE" in assertion.submods.confidential_space.support_attributes
assertion.swname Chaîne définie

Vérifie le logiciel exécuté sur l'entité de test. La valeur est toujours CONFIDENTIAL_SPACE.

Exemple
assertion.swname == "CONFIDENTIAL_SPACE"
assertion.swversion Tableau de chaînes.

Vérifie la version logicielle de l'image Confidential Space. Nous vous recommandons d'utiliser assertion.submods.confidential_space.support_attributes pour cibler la dernière version d'une image.

Exemple
int(assertion.swversion[0]) == 230103

Assertions de conteneur

Assertion Type Description

assertion.submods.container.cmd_override

Interagit avec :

  • Auteur de la charge de travail : règle de lancement allow_cmd_override .
  • Opérateur de charge de travail : variable de métadonnées tee-cmd .
 Tableau de chaînes.

Vérifie les commandes et les paramètres CMD utilisés dans l'image de charge de travail.

Exemples

Le code suivant vérifie que l'objet CMD de l'image de charge de travail n'a pas été écrasé :

size(assertion.submods.container.cmd_override) == 0

Le code suivant vérifie que program est le seul contenu dans les remplacements CMD :

assertion.submods.container.cmd_override == ['program']

assertion.submods.container.env

Interagit avec :

 Objet JSON

Vérifie que les variables d'environnement et leurs valeurs ont été explicitement transmises au conteneur.

Exemple

Le code suivant vérifie que la variable d'environnement example-env-1 est définie sur value-1 et que example-env-2 est définie sur value-2.

assertion.submods.container.env == {"example-env-1": "value-1", "example-env-2": "value-2"}

assertion.submods.container.env_override

Interagit avec :

 Chaîne

Vérifie si l'opérateur de charge de travail a écrasé les variables d'environnement dans le conteneur.

Exemples

Le code suivant vérifie que l'opérateur de charge de travail n'a pas remplacé la variable d'environnement example :

!has(assertion.submods.container.env_override.example)

Le code suivant vérifie que l'opérateur de charge de travail n'a écrasé aucune variable d'environnement :

size(assertion.submods.container.env_override) == 0
assertion.submods.container.image_digest Chaîne

Vérifie le condensé de l'image du conteneur de charge de travail. Spécifier cette condition permet à plusieurs parties d'accepter une charge de travail autorisée et autorisée à accéder à leurs données.

Exemple
assertion.submods.container.image_digest == "sha256:837ccb607e312b170fac7383d7ccfd61fa5072793f19a25e75fbacb56539b86b"
assertion.submods.container.image_id Chaîne

Vérifie l'ID d'image du conteneur de charge de travail.

Exemple
assertion.submods.container.image_id == "sha256:652a44b0e911271ba07cf2915cd700fdfa50abd62a98f87a57fdebc59843d93f"

assertion.submods.container.image_reference

Interagit avec :

 Chaîne

Vérifie l'emplacement du conteneur de charge de travail exécuté sur l'image Confidential Space.

Exemple
assertion.submods.container.image_reference == "us-docker.pkg.dev/PROJECT_ID/WORKLOAD_CONTAINER:latest"

assertion.submods.container.image_signatures

Interagit avec :

 Objet JSON

Vérifie que l'image possède une certaine signature ou qu'elle est signée par une clé publique et un algorithme de signature. Spécifier cette condition permet à plusieurs parties d'accepter une charge de travail autorisée et autorisée à accéder à leurs données.

L'assertion peut inclure les éléments suivants :

  • key_id : empreinte hexadécimale de la clé publique. Pour obtenir l'empreinte, vous pouvez exécuter la commande suivante :

    openssl pkey -pubin -in public_key.pem -outform DER | openssl sha256

    Où public_key.pem correspond à votre clé publique au format PEM.

  • signature : signature d'une charge utile associée au conteneur signé et qui suit le format Simple Signing.

  • signature_algorithm : algorithme utilisé pour signer la clé. Choisissez l'une des options suivantes :

    • RSASSA_PSS_SHA256 (RSASSA-PSS avec un condensé SHA-256)
    • RSASSA_PKCS1V15_SHA256 (RSASSA-PKCS1 v1_5 avec un condensé SHA-256)
    • ECDSA_P256_SHA256 (ECDSA sur la courbe P-256 avec un condensé SHA-256)
Exemple
assertion.swname == 'CONFIDENTIAL_SPACE' && ['ECDSA_P256_SHA256:PUBLIC_KEY_FINGERPRINT'].exists(fingerprint, fingerprint in assertion.submods.container.image_signatures.map(sig, sig.signature_algorithm+':'+sig.key_id)) && 'serviceaccount.iam.gserviceaccount.com' in assertion.google_service_accounts"

assertion.submods.container.restart_policy

Interagit avec :

 Chaîne définie

Vérifie la règle de redémarrage du lanceur de conteneurs lorsque la charge de travail s'arrête.

Les valeurs valides sont les suivantes :

  • Never (par défaut)
  • Always
  • OnFailure
Exemple
assertion.submods.container.restart_policy == "Never"

Assertions de VM

Assertion Type Description

assertion.google_service_accounts

Interagit avec :

 Tableau de chaînes.

Vérifie qu'un compte de service spécifié est associé à la VM qui exécute la charge de travail ou a été répertorié à l'aide de tee-impersonate-service-accounts dans les métadonnées de la VM.

Exemple
workload-service-account@my-project.iam.gserviceaccount.com in assertion.google_service_accounts
assertion.hwmodel Chaîne

Vérifie la technologie d'informatique confidentielle sous-jacente. Les plates-formes compatibles sont les suivantes :

  • GCP_AMD_SEV
  • INTEL_TDX
Exemple
assertion.hwmodel == "GCP_AMD_SEV"

assertion.submods.confidential_space.monitoring_enabled

Interagit avec :

 Booléen

Vérifie l'état de la surveillance sur l'entité d'attestation.

Exemple
assertion.submods.confidential_space.monitoring_enabled.memory == true
assertion.submods.gce.instance_id Chaîne

Valide l'ID de l'instance de VM.

Exemple
assertion.submods.gce.instance_id == "0000000000000000000"
assertion.submods.gce.instance_name Chaîne

Vérifie le nom de l'instance de VM.

Exemple
assertion.submods.gce.instance_name == "workload-vm"
assertion.submods.gce.project_id Chaîne

Permet de vérifier que la VM exécute un projet Google Cloud avec l'ID de projet spécifié.

Exemple
assertion.submods.gce.project_id == "project-id"
assertion.submods.gce.project_number Chaîne

Vérifie que la VM est en cours d'exécution dans un projet Google Cloud avec le numéro de projet spécifié.

Exemple
assertion.submods.gce.project_number == "00000000000"

assertion.submods.gce.zone

Interagit avec :

  • Opérateur de charge de travail : valeur --zone .
 Chaîne

Vérifie que la VM est en cours d'exécution dans la zone spécifiée.

Exemple
assertion.submods.gce.zone == "us-central1-a"

assertion.submods.nvidia_gpu.cc_mode

Interagit avec :

 Chaîne définie

Vérifie l'état du pilote informatique confidentielle de NVIDIA. Les valeurs valides sont les suivantes :

  • OFF : aucune des fonctionnalités NVIDIA Confidential Computing n'est active.
  • ON : le matériel, le micrologiciel et le logiciel NVIDIA H100 ont entièrement activé les fonctionnalités de confidential computing.
  • DEVTOOLS : le GPU est dans un mode de calcul confidentiel partiel qui correspond aux workflows du mode ON, mais désactive les protections de sécurité.
Exemple
assertion.submods.nvidia_gpu.cc_mode == "ON"