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

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

De plus, les collaborateurs de données doivent choisir l'emplacement de stockage des résultats de la charge de travail Confidential Space, et si ces résultats sont uniques pour chaque collaborateur ou partagés. Vous pouvez, par exemple, choisir de générer le même résultat dans 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 qui stocke 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 s'il s'agissait d'un compte principal dans votre propre projet. Vous pouvez ainsi lui attribuer des rôles IAM pour lui donner accès à des ressources spécifiques, ou 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 WIP 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 :

  • Un service d'attestation : ce service vérifie que la charge de travail est une instance Confidential VM 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é, qui doit correspondre au service d'attestation ajouté au fournisseur WIP pour que l'accès soit accordé.

  • Mappages d'attributs : attributs des jetons d'accès Security Token Service qui sont mappés aux assertions effectuées par l'entité d'authentification (dans ce cas, 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 pistes d'audit dans Cloud Logging et pour accorder des rôles via IAM sur la base d'assertions d'entités d'authentification, telles que les condensés de conteneurs d'images 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 d'authentification doivent remplir pour obtenir l'accès, en fonction des assertions qu'elles effectuent.

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 la charge de travail, qui vérifie l'instance Confidential VM, 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, et le fournisseur l'utilise pour vérifier que les assertions respectent la règle d'attestation définie dans le fournisseur. Si c'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é 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 implique de configurer une identité fédérée dans un fournisseur de pool d'identités de charge de travail associé aux assertions d'une entité d'authentification. De cette façon, une charge de travail peut être autorisée à accéder aux ressources directement 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 des 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, déterminées 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 fournir à un acteur malveillant 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 emprunté qui peut être partagée 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 du projet à partir duquel la charge de travail est exécutée et l'ID de l'instance de VM exécutant la charge de travail, ce qui fournit une piste d'audit plus détaillée.

  • Vous n'avez pas besoin de mapper la propriété d'instance de VM selfLink à 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é d'un 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 WIP. Ils spécifient également le compte de service de la charge de travail dans leur fournisseur WIP, ce qui permet au compte de service de la charge de travail d'emprunter l'identité des comptes de service des collaborateurs de données afin de récupérer leurs données confidentielles et d'effectuer des opérations sur celles-ci.

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

La méthode d'emprunt d'identité d'un compte de service peut échouer à 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 implique de configurer un WIP et un fournisseur, puis de 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, procédez comme suit :

  1. Créez le pool d'identités de charge de travail :

    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="ISSUER_URI" \
    --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 :

    • Un issuer-uri qui correspond au service d'attestation que vous utilisez :

      • Google Cloud Attestation : https://confidentialcomputing.googleapis.com

      • Intel Trust Authority : https://portal.trustauthority.intel.com

    • allowed-audiences de https://sts.googleapis.com. Il s'agit du Security Token Service 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 langage 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 aux 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é afin que vous puissiez attribuer 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 forment 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 en savoir plus sur les conditions d'attribut que vous pouvez utiliser, consultez Créer une règle d'attestation.

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

Après avoir créé un fournisseur WIP, vous pouvez attribuer un rôle IAM à l'identité fédérée selon que le condensé du conteneur d'image de charge de travail de l'identité correspond ou non à 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é d'un compte de service implique les éléments suivants :

  1. Créer des comptes de service dans chacun des projets des collaborateurs de données et leur accorder l'autorisation de déchiffrer les données confidentielles.

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

  3. Créer des fournisseurs WIP dans chaque WIP, qui spécifient le compte de service de la charge de travail comme compte autorisé à emprunter l'identité des comptes de service des collaborateurs de données.

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

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

    gcloud iam service-accounts create DATA_COLLABORATOR_SERVICE_ACCOUNT_NAME

    Accordez aux comptes de service les autorisations requises pour déchiffrer les données confidentielles. Par exemple, vous pouvez chiffrer des fichiers confidentiels dans Cloud Storage avec Cloud KMS. Vous devez donc autoriser le compte de service à 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 pool d'identité de charge de travail et un fournisseur, suivez les instructions ci-dessous dans chaque projet de collaborateur de données :

  1. Créez le pool d'identités de charge de travail :

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

  2. Associez le compte de service dont l'identité sera empruntée au pool d'identité 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 la 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 :

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

    • allowed-audiences de https://sts.googleapis.com. Il s'agit du Security Token Service 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 forment 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 de conteneur de la 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 en savoir plus sur les conditions d'attribut que vous pouvez utiliser, consultez Créer une règle d'attestation.

Créer une règle d'attestation

Lorsque vous créez un WIP, vous devez créer une règle d'attestation. Les assertions d'une entité d'authentification doivent correspondre à votre stratégie 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 de 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 utilise une image Confidential Space STABLE et que la zone dans laquelle l'instance de VM de charge de travail s'exécute soit 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 effectuées par l'image Confidential Space, le conteneur de charge de travail et l'instance de VM.

Assertions d'image

Assertion Type Description

assertion.dbgstat

Interagit avec :

 Enumeration

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

Les valeurs valides sont les suivantes :

  • enable : vérifier 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 en 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.

Le tableau suivant décrit les attributs de compatibilité des images de production Confidential Space.

Attribut de compatibilité Description

LATEST

Les images LATEST possèdent également les attributs de compatibilité suivants :

  • STABLE
  • USABLE

Durée de vie de l'image : environ un mois. Ensuite, l'attribut de compatibilité LATEST est supprimé.

Il s'agit de la dernière version de l'image Confidential Space. Elle est compatible et surveillée pour détecter les failles.

Pour les charges de travail de longue durée, nous vous recommandons de ne pas spécifier LATEST dans votre règle d'attestation. En effet, l'image Confidential Space peut être mise à jour pendant l'exécution de votre charge de travail, ce qui signifie que l'image Confidential Space que vous utilisez n'est plus LATEST et que votre charge de travail échoue à l'attestation lors de l'actualisation suivante du jeton par défaut de Confidential Space.

STABLE

Les images STABLE possèdent également les attributs de compatibilité suivants :

  • USABLE

Durée de vie de l'image : environ six mois. À partir du 1er avril 2027, l'attribut de compatibilité STABLE sera supprimé à l'expiration de la durée de vie de l'image.

Les images dotées de l'attribut STABLE sont compatibles et surveillées pour détecter les failles pendant une période de six mois. Nous vous recommandons d'écrire une règle d'attestation basée sur l'attribut STABLE.

Dans de rares cas, l'attribut STABLE peut être supprimé pendant la période d'assistance normale de six mois, par exemple lorsque des failles critiques sont découvertes.

USABLE

Les images ne comportant que l'attribut USABLE sont toujours disponibles, mais sont considérées comme obsolètes. Les images obsolètes ne sont pas acceptées et datent de plus de six mois. Vous les utilisez à vos propres risques.

Les images USABLE ont une propriété deprecated.deprecated. Sa valeur correspond au code temporel de la date d'abandon prévue de l'image. Les propriétés d'une image peuvent être affichées à l'aide de la commande gcloud compute images describe ou de la méthode REST images.get. Exemple : 

gcloud compute images describe confidential-space-240800 \
    --format=json \
    --project=confidential-space-images
EXPERIMENTAL

Les images ne comportant que cet attribut utilisent des fonctionnalités en preview. Les images EXPERIMENTAL sont destinées uniquement à des fins de test et ne doivent jamais être utilisées en production.

Une image EXPERIMENTAL ne comporte jamais les attributs LATEST, STABLE ou USABLE.

Nous vous recommandons de maintenir votre image Confidential Space à jour. Pour savoir comment mettre à jour votre image Confidential Space, consultez Mettre à jour les images Confidential Space.

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 Enumeration

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 pour les conteneurs

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éfini 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 la 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 est votre clé publique au format PEM.

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

  • 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
['ECDSA_P256_SHA256:PUBLIC_KEY_FINGERPRINT'].exists(fingerprint, fingerprint in assertion.submods.container.image_signatures.map(sig, sig.signature_algorithm+':'+sig.key_id))

assertion.submods.container.restart_policy

Interagit avec :

 Enumeration

Vérifie la stratégie 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 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

Vérifie 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

Vérifie que la VM exécute un projet Google Cloud avec l'ID du 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_feature

Interagit avec :

 Enumeration

Vérifie les fonctionnalités d'informatique confidentielle compatibles avec un GPU NVIDIA. Seul le mode de transfert GPU unique (SPT) est compatible avec Confidential Space. La valeur est donc toujours SPT.

Pour en savoir plus sur la compatibilité de l'informatique confidentielle NVIDIA, consultez NVIDIA Trusted Computing Solutions (PDF).

Exemple
assertion.submods.nvidia_gpu.cc_feature == "SPT"

assertion.submods.nvidia_gpu.cc_mode

Interagit avec :

 Enumeration

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

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

assertion.submods.nvidia_gpu.gpus

Interagit avec :

 Tableau d'objets

Vérifie les revendications pour chaque GPU NVIDIA attesté. Confidential Space n'accepte qu'une seule revendication de GPU.

Un objet gpus ressemble à ce qui suit :

{
  "hwmodel": "GCP_NVIDIA_H100",
  "ueid": "490457405999046854973671575630853621547794591064",
  "l4_serial_number": "1216669666319372030078",
  "driver_version": "570.00",
  "vbios_version": "96.00.9F.00.01"
}
Exemples

Le code suivant vérifie que le premier modèle de matériel GPU est un NVIDIA H100 exécuté sur Google Cloud : 

assertion.submods.nvidia_gpu.gpus[0].hwmodel == "GCP_NVIDIA_H100"

Le code suivant vérifie que la revendication d'attestation comporte des revendications liées au GPU : 

has(assertion.submods.nvidia_gpu.gpus)