Vertrauliche Ressourcen erstellen und Zugriff darauf gewähren

Data Collaborators

Datenmitbearbeiter müssen die folgenden Ressourcen einrichten, damit eine Arbeitslast auf ihre vertraulichen Daten zugreifen kann:

• Verschlüsselte Daten, die in Google Cloudgespeichert sind.

• Workload Identity-Pool (WIP) zum Autorisieren der Arbeitslast. Nachdem eine Arbeitslast von einem WIP autorisiert wurde, kann sie auf vertrauliche Daten von Datenmitarbeitern zugreifen und diese verarbeiten.

Außerdem müssen Datenmitwirkende auswählen, wo die Ergebnisse der Confidential Space-Arbeitslast gespeichert werden und ob diese Ergebnisse für jeden Mitwirkenden eindeutig sind oder freigegeben werden. Sie können beispielsweise dasselbe Ergebnis in mehrere Cloud Storage-Buckets ausgeben, die zu den einzelnen Datenmitwirkenden gehören.

Hinweis :Wenn Ressourcen von Datenmitarbeitern nicht von Google CloudIAM verwaltet werden, kann der Zugriff auf diese Ressourcen durch Anfordern von Attestierungstokens mit benutzerdefinierten Zielgruppen und optionalen Nonces verwaltet werden. Arbeiten Sie mit dem Autor der Arbeitslast zusammen, um dies zu implementieren. Weitere Informationen finden Sie unter Zugriff auf Ressourcen, die nicht von Google Cloud IAM verwaltet werden.

Verschlüsselte Daten speichern

Sie können jeden Google Cloud Dienst verwenden, in dem Daten gespeichert werden, um Ihre vertraulichen Daten zu hosten. Beispielsweise können Sie einen der folgenden Dienste verwenden:

• BigQuery

• Cloud SQL

• Cloud Storage

• Filestore

• Persistent Disk

Sie sollten dafür sorgen, dass diese Daten im Ruhezustand verschlüsselt werden, entweder mit integrierten Funktionen oder mit einem Dienst wie Cloud Key Management Service (Cloud KMS).

Achtung :Verwenden Sie beim Testen einer Arbeitslast für Daten keine privaten Informationen. Richten Sie gefälschte Daten im selben Format ein und testen Sie damit, bis Sie bereit sind, die Arbeitslast zu sperren.

Arbeitslast mit einem WIP autorisieren

Eine WIP (Workload Identity Pool, WIP) ist der Mechanismus, mit dem Confidential Space einer externen Arbeitslast den Zugriff auf Ihre vertraulichen Daten als föderierte Identität ermöglicht. Eine föderierte Identität ist eine externe Identität, die so behandelt wird, als wäre sie ein Principal in Ihrem eigenen Projekt. So können Sie ihr IAM-Rollen zuweisen, um Zugriff auf bestimmte Ressourcen zu gewähren oder die Identität von Dienstkonten zu übernehmen, um dasselbe zu tun.

Als Datenpartner richten Sie in einem WIP einen Anbieter ein, der die Regeln für Entitäten festlegt, die sich als föderierte Identität authentifizieren. Für Confidential Space müssen Sie in einem Anbieter Folgendes definieren:

• Ein Attestierungsdienst: Dieser Dienst prüft, ob die Arbeitslast eine Confidential VM-Instanz ist, und gibt letztendlich ein OpenID Connect-Attestierungstoken (OIDC) an den WIP-Anbieter zurück. Der Arbeitslastoperator legt den verwendeten Attestierungsdienst fest. Dieser muss mit dem Attestierungsdienst übereinstimmen, der dem WIP-Anbieter hinzugefügt wurde, damit der Zugriff gewährt wird.

• Attributzuordnungen: Attribute in Zugriffstokens des Security Token Service, die Assertionen der authentifizierenden Identität zugeordnet sind. In diesem Fall ist das die VM-Instanz, auf der die Arbeitslast ausgeführt wird. Assertionen werden von der VM-Instanz selbst, dem Confidential Space-Image und dem Arbeitslastcontainer erstellt und von der Arbeitslast an den WIP-Anbieter übergeben. Diese Attribute werden für Dinge wie Audit-Trails in Cloud Logging verwendet und um Rollen über IAM auf der Grundlage von Assertionen der authentifizierenden Identität zu gewähren, z. B. Arbeitslast-Image-Container-Digests. Weitere Informationen zu Attributzuordnungen

• Eine Attestierungsrichtlinie: Eine Reihe von Bedingungen, die authentifizierende Einheiten erfüllen müssen, um auf Grundlage ihrer Behauptungen Zugriff zu erhalten.

Wenn eine Arbeitslast gestartet wird, sendet der Confidential Space Launcher seinen Attestierungsbericht an einen vom Arbeitslastoperator definierten Attestierungsdienst, der die Confidential VM-Instanz überprüft und dann ein OIDC-Attestierungstoken zurückgibt. Dieses Token ist eine Stunde lang gültig und wird automatisch aktualisiert.

Das Attestierungstoken wird dann von der Arbeitslast an den WIP-Anbieter übergeben. Der Anbieter verwendet es, um zu prüfen, ob die Assertions die im Anbieter definierte Attestierungsrichtlinie erfüllen. Wenn dies der Fall ist, darf die Arbeitslast auf die vertraulichen Ressourcen zugreifen.

Hinweis: Anstatt die Server von Google zur Tokenvalidierung zu verwenden, können Sie Bestätigungstokens selbst mit Langzeitzertifikaten validieren.

Zugriff auf externe Arbeitslasten

Bevor Sie eine WIP und einen Anbieter einrichten, müssen Sie festlegen, wie die Arbeitslast auf Ihre Ressourcen zugreifen soll: direkter Ressourcenzugriff oder Identitätswechsel des Dienstkontos.

Direkter Ressourcenzugriff

Wir empfehlen die Methode des direkten Ressourcenzugriffs für Arbeitslasten.

Bei dieser Methode wird eine föderierte Identität in einem WIP-Anbieter eingerichtet, die an die Zusicherungen einer authentifizierenden Identität gebunden ist. So kann eine Arbeitslast autorisiert werden, direkt über IAM-Bindungen auf Ressourcen zuzugreifen, basierend auf Attributen wie dem Container-Image-Digest der Arbeitslast.

Der direkte Ressourcenzugriff bietet folgende Vorteile:

• Das Einrichten einer Confidential Space-Umgebung erfordert weniger Schritte, da Datenmitarbeiter keine Dienstkonten einrichten müssen, die von einem Workload-Dienstkonto übernommen werden.

• Die Arbeitslast darf nur auf bestimmte Ressourcen zugreifen, die von IAM festgelegt werden. Diese Methode ist sicherer als die Identitätsübernahme des Dienstkontos, bei der überberechtigte Dienstkonten oder Identitätsübernahmerechte einem böswilligen Akteur mehr Zugriff als beabsichtigt gewähren können.

• Jeder Ressourcenzugriff wird mit der föderierten Identität einer VM-Instanz für Arbeitslasten protokolliert, anstatt mit der Identität eines imitierten Dienstkontos, das möglicherweise von mehreren Arbeitslasten gemeinsam genutzt wird. Die Identität einer VM-Instanz für Arbeitslasten kann Details wie den Image-Digest eines Containers, die Projektnummer, aus der die Arbeitslast ausgeführt wird, und die ID der VM-Instanz, auf der die Arbeitslast ausgeführt wird, enthalten. So wird ein detaillierterer Prüfpfad bereitgestellt.

• Sie müssen die selfLink-Property der VM-Instanz nicht dem Attribut google.subject in einem WIP-Anbieter zuordnen. Sehr lange selfLink-Werte können das 127-Byte-Limit dieses Attributs überschreiten, was dazu führt, dass die WIP-Anbieterauthentifizierung fehlschlägt.

Identitätsübernahme des Dienstkontos

Bei der Methode zur Identitätsübernahme von Dienstkonten richtet jeder Datenpartner ein Dienstkonto zum Entschlüsseln seiner privaten Daten ein und hängt dieses Dienstkonto dann an seinen eigenen WIP an. Er gibt auch das Dienstkonto der Arbeitslast in seinem WIP-Anbieter an, sodass das Dienstkonto der Arbeitslast die Identität der Dienstkonten der Datenpartner übernehmen kann, um ihre vertraulichen Daten abzurufen und zu verarbeiten.

Die Identitätsübernahme des Dienstkontos sollte nur in den folgenden Szenarien verwendet werden:

• Wenn Sie Image-Signaturen als Authentifizierungsanmeldedaten verwenden müssen, da die von Signaturen verwendete Syntax nicht mit Attributzuordnungen funktioniert.

• Wenn Sie auf APIs zugreifen, die keine föderierten Identitäten unterstützen.

Die Methode zur Übernahme der Identität eines Dienstkontos kann bei der Authentifizierung bei einem WIP-Anbieter fehlschlagen, wenn eine VM-Instanz ein sehr langes selfLink-Attribut hat. Das liegt daran, dass die sub-Anforderung im Attestierungstoken, die auf den selfLink-Wert festgelegt ist, im WIP-Bereitsteller dem google.subject-Attribut zugeordnet wird, das ein Limit von 127 Byte hat.

Bei selfLink-Werten für VM-Instanzen, die 127 Byte überschreiten, müssen Sie Ihre VM-Instanzen umbenennen, um die selfLink zu verkürzen, oder stattdessen die Methode für den direkten Ressourcenzugriff verwenden.

WIP und Anbieter einrichten

Die Schritte zum Einrichten eines Anbieters variieren je nachdem, ob Sie den direkten Ressourcenzugriff oder die Identitätsübernahme des Dienstkontos verwenden.

Direkter Ressourcenzugriff

Bei der Methode für den direkten Ressourcenzugriff müssen Sie einen WIP und einen Anbieter einrichten und dann IAM-Rollen basierend auf einem bestimmten Digest des Arbeitslast-Container-Images einrichten.

WIP und Anbieter einrichten

So richten Sie ein WIP und einen Bereitsteller ein:

1. WIP erstellen:

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

2. OIDC-Anbieter im WIP erstellen:

   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"
   

   In diesem Beispiel werden die folgenden Werte verwendet:

   • Ein issuer-uri, das dem von Ihnen verwendeten Attestierungsdienst entspricht:

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

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

   • Ein allowed-audiences von https://sts.googleapis.com. Dies ist der Security Token Service von Google, der Anmeldedaten gegen Zugriffstokens austauscht.

   • Ein attribute-mapping-Wert von google.subject mit dem folgenden Wert:

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

     Dieser Wert wird mit der Common Expression Language (CEL) erstellt. Dem Attribut gcpcs werden die folgenden Werte zugewiesen, die in Cloud Logging angezeigt werden, wenn die Arbeitslast auf Ressourcen zugreift:

     • assertion.submods.container.image_digest: Der Digest des Container-Images für die Arbeitslast.

     • assertion.submods.gce.project_number: Die Projektnummer der VM-Instanz.

     • assertion.submods.gce.instance_id: Die ID der VM-Instanz.

     Außerdem wird attribute.image_digest auf assertion.submods.container.image_digest, den Digest des Arbeitslastcontainer-Images, festgelegt. Dieses Attribut wird zugeordnet, damit Sie der föderierten Identität IAM-Rollen auf Grundlage eines bestimmten Image-Digests zuweisen können.

     Sie können beliebige der verfügbaren Arbeitslast-Assertions zuordnen, solange die Gesamtlänge des google.subject-Werts weniger als 127 Byte beträgt.

   • Die folgenden attribute-conditions bilden eine Attestierungsrichtlinie. Wenn diese Bedingungen mit den Zusicherungen der Arbeitslast übereinstimmen, darf die Arbeitslast als föderierte Identität auf die vertraulichen Ressourcen zugreifen:

     • assertion.swname == 'CONFIDENTIAL_SPACE': Bestätigt, dass Confidential Space die Software ist, die auf der VM ausgeführt wird, mit allen integrierten Sicherheitsgarantien.

     • 'STABLE' in assertion.submods.confidential_space.support_attributes: Prüft, ob das Confidential Space-Produktions-Image verwendet wird und das STABLE-Attribut „support“ hat.

     Weitere Attributbedingungen, die Sie verwenden können, finden Sie unter Attestierungsrichtlinie erstellen.

IAM-Rollen für die föderierte Identität gewähren

Nachdem Sie einen WIP-Anbieter erstellt haben, können Sie der föderierten Identität eine IAM-Rolle zuweisen, je nachdem, ob der Container-Digest des Arbeitslast-Images der Identität mit einem erwarteten Wert übereinstimmt.

Im folgenden Beispiel wird einer föderierten Identität die Berechtigung zum Entschlüsseln eines bestimmten Cloud Key Management Service-Schlüssels erteilt:

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

Identitätsübernahme des Dienstkontos

Die Methode der Dienstkonto-Identitätsübernahme umfasst Folgendes:

1. Dienstkonten in jedem der Projekte der Datenkooperationspartner erstellen und ihnen die Berechtigung zum Entschlüsseln der vertraulichen Daten gewähren.

2. Erstellen Sie WIPs in jedem der Projekte der Datenpartner und hängen Sie dann das gerade erstellte Dienstkonto jedes Projekts an den jeweiligen WIP an.

3. Erstellen Sie WIP-Anbieter in jedem WIP, in denen das Dienstkonto der Arbeitslast als das Konto angegeben wird, das die Identität der Dienstkonten der Datenmitarbeiter übernehmen darf.

Dienstkonten zum Entschlüsseln vertraulicher Daten einrichten

1. Erstellen Sie die Dienstkonten in den Projekten der Datenpartner:

   gcloud iam service-accounts create DATA_COLLABORATOR_SERVICE_ACCOUNT_NAME
   

   Gewähren Sie den Dienstkonten die Berechtigungen, die zum Entschlüsseln der vertraulichen Daten erforderlich sind. Sie können beispielsweise vertrauliche Dateien in Cloud Storage mit Cloud KMS verschlüsseln. Dazu müssen Sie dem Dienstkonto die Berechtigung zum Entschlüsseln dieser Daten erteilen:

   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
   

WIP und Anbieter einrichten

So richten Sie ein WIP und einen Anbieter ein:

1. WIP erstellen:

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

2. Hängen Sie das Dienstkonto, das imitiert werden soll, an das WIP an und weisen Sie ihm die Rolle roles/iam.workloadIdentityUser zu:

   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. Erstellen Sie einen OIDC-Anbieter im WIP und definieren Sie das Dienstkonto der Workload darin, damit es die Identität des Dienstkontos des Daten-Collaborators übernehmen kann:

   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"
   

   In diesem Beispiel werden die folgenden Werte verwendet:

   • Eine issuer-uri von https://confidentialcomputing.googleapis.com/, was bedeutet, dass Google Cloud Attestation als Attestierungsdienst verwendet wird.

   • Ein allowed-audiences von https://sts.googleapis.com. Dies ist der Security Token Service von Google, der Anmeldedaten gegen Zugriffstokens austauscht.

   • Ein attribute-mapping von google.subject mit dem Wert assertion.sub. Dies ist die selfLink der VM-Instanz, wie im sub-Anspruch im Attestierungstoken definiert.

     Die VM-Instanz selfLink wird in Cloud Logging angezeigt, wenn die Arbeitslast auf Ressourcen zugreift.

   • Die folgenden attribute-conditions bilden eine Attestierungsrichtlinie. Wenn diese Bedingungen mit den Zusicherungen der Arbeitslast übereinstimmen, darf die Arbeitslast als föderierte Identität auf Ressourcen zugreifen:

     • assertion.submods.container.image_digest == 'WORKLOAD_CONTAINER_IMAGE_DIGEST': Prüft, ob der Digest des Arbeitslast-Container-Images mit dem erwarteten Wert übereinstimmt.

     • 'WORKLOAD_SERVICE_ACCOUNT_NAME@WORKLOAD_PROJECT_ID.iam.gserviceaccount.com' in assertion.google_service_accounts: Prüft, ob das Dienstkonto, das der Arbeitslast zugeordnet ist, mit dem erwarteten Dienstkonto übereinstimmt, und verwendet es dann, um die Identität des Dienstkontos des Datenkooperationspartners zu übernehmen.

     • assertion.swname == 'CONFIDENTIAL_SPACE': Bestätigt, dass Confidential Space die Software ist, die auf der VM ausgeführt wird, mit allen integrierten Sicherheitsgarantien.

     • 'STABLE' in assertion.submods.confidential_space.support_attributes: Prüft, ob das Confidential Space-Produktions-Image verwendet wird und das STABLE-Attribut „support“ hat.

     Weitere Attributbedingungen, die Sie verwenden können, finden Sie unter Attestierungsrichtlinie erstellen.

Attestierungsrichtlinie erstellen

Beim Erstellen eines WIP müssen Sie eine Attestierungsrichtlinie erstellen. Die Zusicherungen einer authentifizierenden Entität müssen mit Ihrer Richtlinie übereinstimmen, damit auf Ihre Daten zugegriffen werden kann.

Richtlinien werden in der Common Expression Language (CEL) geschrieben und bestehen aus einer Reihe von Anweisungen, die mit dem &&-Operator verkettet werden können.

In den Anweisungen werden Zusicherungen aus dem Confidential Space-Image, dem Arbeitslast-Container-Image oder der VM-Instanz als Variablen und der von Ihnen angegebene Wert als Ausdruck verwendet. Hier ist ein Beispiel für eine Richtlinie, die erzwingt, dass die Arbeitslast Confidential Space verwendet, ein STABLE-Confidential Space-Image verwendet werden muss und die Zone, in der die VM-Instanz der Arbeitslast ausgeführt wird, us-central1-a sein muss:

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

Weitere Informationen finden Sie unter Attestierungsbehauptungen.

Attestierungs-Assertions

Die verfügbaren Zusicherungen zum Erstellen einer Attestrichtlinie sind in der folgenden Tabelle aufgeführt. Mit Richtlinien können Assertions validiert werden, die vom Confidential Space-Image, vom Arbeitslastcontainer und von der VM-Instanz gemacht werden.

Bildbehauptungen

Assertion	Typ	Beschreibung
assertion.dbgstat Interagiert mit: Arbeitslastoperator: Der Wert --image-family.	Aufzählung	Prüft, ob das Confidential Space-Image die Debugging- oder Produktionsversion ist. Die gültigen Werte sind: enable: Prüfen Sie, ob das Debug-Image verwendet wird. disabled-since-boot: Prüfen Sie, ob das Produktions-Image verwendet wird. Beispiele Der folgende Code prüft, ob die Debugging-Version des Confidential Space-Images verwendet wird: assertion.dbgstat == "enable" Der folgende Code prüft, ob die Produktionsversion des Confidential Space-Images verwendet wird: assertion.dbgstat == "disabled-since-boot"
assertion.submods.confidential_space.support_attributes	String-Array	Prüft die Sicherheitsversion des Confidential Space-Produktions-Images, das auf der Confidential VM-Instanz ausgeführt wird, anhand der zugehörigen Support-Attribute. Für Debug-Images im Confidential Space ist kein „support“-Attribut festgelegt. Gültige Supportattribute sind: LATEST: Dies ist die aktuelle Version des Images und sie wird unterstützt. Das LATEST-Bild ist auch STABLE und USABLE. STABLE: Diese Version des Images wird unterstützt und auf Sicherheitslücken überwacht. Ein STABLE-Bild ist auch USABLE. USABLE: Ein Image mit nur diesem Attribut wird nicht mehr unterstützt und nicht mehr auf Sicherheitslücken überwacht. Sie gehen dabei auf eigenes Risiko vor. EXPERIMENTAL: Ein Bild mit nur diesem Attribut nutzt Vorschaufunktionen. Er ist nur für Testzwecke vorgesehen und sollte nie in der Produktion verwendet werden. Ein EXPERIMENTAL-Bild hat nie die Attribute LATEST, STABLE oder USABLE. Achtung: Da das Standard-Token für Confidential Space stündlich aktualisiert wird, wird die Angabe von LATEST für lang andauernde Arbeitslasten nicht empfohlen. Das Confidential Space-Image wird möglicherweise aktualisiert, während Ihre Arbeitslast ausgeführt wird. Das bedeutet, dass die Arbeitslast nicht mehr die neueste Version verwendet und die Attestierung fehlschlägt. Beispiel Der folgende Code prüft, ob eine stabile Version des Confidential Space-Images verwendet wird: "STABLE" in assertion.submods.confidential_space.support_attributes
assertion.swname	Aufzählung	Verifiziert die Software, die auf der attestierenden Entität ausgeführt wird. Der Wert ist immer CONFIDENTIAL_SPACE. Beispiel assertion.swname == "CONFIDENTIAL_SPACE"
assertion.swversion	String-Array	Verifiziert die Softwareversion des Confidential Space-Image. Wir empfehlen, stattdessen assertion.submods.confidential_space.support_attributes zu verwenden, um die neueste Version eines Bildes anzusprechen. Beispiel int(assertion.swversion[0]) == 230103

Container-Assertions

Assertion	Typ	Beschreibung
assertion.submods.container.cmd_override Interagiert mit: Arbeitslastautor: Die allow_cmd_override-Einführungsrichtlinie. Arbeitslastoperator: Die Metadatenvariable tee-cmd.	String-Array	Verifiziert die CMD-Befehle und -Parameter, die im Arbeitslast-Image verwendet werden. Beispiele Mit dem folgenden Code wird überprüft, ob der CMD des Arbeitslast-Images nicht überschrieben wurde: size(assertion.submods.container.cmd_override) == 0 Der folgende Code prüft, ob program der einzige Inhalt in den CMD-Überschreibungen ist: assertion.submods.container.cmd_override == ['program']
assertion.submods.container.env Interagiert mit: Arbeitslastautor: Die allow_env_override-Einführungsrichtlinie. Arbeitslastoperator: Die Metadatenvariable tee-env-ENVIRONMENT_VARIABLE_NAME .	JSON-Objekt	Verifiziert, dass Umgebungsvariablen und deren Werte explizit an den Container übergeben wurden. Beispiel Der folgende Code prüft, ob die Umgebungsvariable example-env-1 auf value-1 und example-env-2 auf value-2 festgelegt ist. assertion.submods.container.env == {"example-env-1": "value-1", "example-env-2": "value-2"}
assertion.submods.container.env_override Interagiert mit: Arbeitslastautor: Die allow_env_override-Einführungsrichtlinie. Arbeitslastoperator: Die Metadatenvariable tee-env-ENVIRONMENT_VARIABLE_NAME .	String	Prüft, ob der Arbeitslastoperator Umgebungsvariablen im Container überschrieben hat. Beispiele Der folgende Code prüft, ob der Workload-Operator die Umgebungsvariable example überschrieben hat: !has(assertion.submods.container.env_override.example) Der folgende Code prüft, ob der Arbeitslastoperator Umgebungsvariablen überschrieben hat: size(assertion.submods.container.env_override) == 0
assertion.submods.container.image_digest	String	Verifiziert den Image-Digest des Arbeitslastcontainers. Durch die Angabe dieser Bedingung können mehrere Parteien einer autorisierten Arbeitslast zustimmen, die auf ihre Daten zugreifen darf. Beispiel assertion.submods.container.image_digest == "sha256:837ccb607e312b170fac7383d7ccfd61fa5072793f19a25e75fbacb56539b86b"
assertion.submods.container.image_id	String	Verifiziert die Image-ID des Arbeitslastcontainers. Beispiel assertion.submods.container.image_id == "sha256:652a44b0e911271ba07cf2915cd700fdfa50abd62a98f87a57fdebc59843d93f"
assertion.submods.container.image_reference Interagiert mit: Arbeitslastoperator: Die Metadatenvariable tee-image-reference.	String	Verifiziert den Speicherort des Arbeitslastcontainers, der auf dem Confidential Space-Image ausgeführt wird. Beispiel assertion.submods.container.image_reference == "us-docker.pkg.dev/PROJECT_ID/WORKLOAD_CONTAINER:latest"
assertion.submods.container.image_signatures Interagiert mit: Arbeitslastoperator: Die Metadatenvariable tee-signed-image-repos.	JSON-Objekt	Prüft, ob das Image eine bestimmte Signatur hat oder mit einem öffentlichen Schlüssel und einem Signaturalgorithmus signiert ist. Durch die Angabe dieser Bedingung können mehrere Parteien einer autorisierten Arbeitslast zustimmen, die auf ihre Daten zugreifen darf. Die Assertion kann die folgenden Elemente enthalten: key_id: Der hexadezimale Fingerabdruck des öffentlichen Schlüssels. Führen Sie den folgenden Befehl aus, um den Fingerabdruck abzurufen: openssl pkey -pubin -in public_key.pem -outform DER | openssl sha256 Dabei ist public_key.pem Ihr öffentlicher Schlüssel im PEM-Format. signature: Die Signatur für eine Nutzlast, die dem signierten Container zugeordnet ist und dem Simple Signing-Format entspricht. signature_algorithm: Der Algorithmus, der zum Signieren des Schlüssels verwendet wird. Eines der folgenden Betriebssysteme: RSASSA_PSS_SHA256 (RSASSA-PSS mit einem SHA-256-Digest) RSASSA_PKCS1V15_SHA256 (RSASSA-PKCS1 v1_5 mit einem SHA-256-Digest) ECDSA_P256_SHA256 (ECDSA auf der P-256-Kurve mit einem SHA-256-Digest) Beispiel ['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 Interagiert mit: Arbeitslastoperator: Die Metadatenvariable tee-restart-policy.	Aufzählung	Überprüft die Neustartrichtlinie des Container-Launchers, wenn die Arbeitslast beendet wird. Die gültigen Werte sind: Never (Standard) Always OnFailure Beispiel assertion.submods.container.restart_policy == "Never"

VM-Assertions

Assertion	Typ	Beschreibung
assertion.google_service_accounts Interagiert mit: Workload-Operator: Die Metadatenvariable tee-impersonate-service-accounts und der Wert --service-account .	String-Array	Prüft, ob ein angegebenes Dienstkonto mit der VM verbunden ist, auf der die Arbeitslast ausgeführt wird, oder mit tee-impersonate-service-accounts in den VM-Metadaten aufgeführt wurde. Beispiel [e-mail] in assertion.google_service_accounts
assertion.hwmodel	String	Überprüft die zugrunde liegende Confidential Computing-Technologie. Die unterstützten Plattformen sind: GCP_AMD_SEV INTEL_TDX Beispiel assertion.hwmodel == "GCP_AMD_SEV"
assertion.submods.confidential_space.monitoring_enabled Interagiert mit: Arbeitslastautor: Die monitoring_memory_allow-Einführungsrichtlinie. Arbeitslastoperator: Die Metadatenvariable tee-monitoring-memory-enable.	Boolesch	Überprüft den Monitoring-Status auf der attestierenden Entität. Beispiel assertion.submods.confidential_space.monitoring_enabled.memory == true
assertion.submods.gce.instance_id	String	Überprüft die VM-Instanz-ID. Beispiel assertion.submods.gce.instance_id == "0000000000000000000"
assertion.submods.gce.instance_name	String	Überprüft den Namen der VM-Instanz. Beispiel assertion.submods.gce.instance_name == "workload-vm"
assertion.submods.gce.project_id	String	Prüft, ob auf der VM ein Google Cloud -Projekt mit der angegebenen Projekt-ID ausgeführt wird. Beispiel assertion.submods.gce.project_id == "project-id"
assertion.submods.gce.project_number	String	Prüft, ob die VM in einem Google Cloud -Projekt mit der angegebenen Projektnummer ausgeführt wird. Beispiel assertion.submods.gce.project_number == "00000000000"
assertion.submods.gce.zone Interagiert mit: Arbeitslastoperator: Der Wert --zone.	String	Prüft, ob die VM in der angegebenen Zone ausgeführt wird. Beispiel assertion.submods.gce.zone == "us-central1-a"
assertion.submods.nvidia_gpu.cc_feature Interagiert mit: Arbeitslastoperator: Die Metadatenvariable tee-install-gpu-driver.	Aufzählung	Prüft die von einer NVIDIA-GPU unterstützten Confidential Computing-Funktionen. In Confidential Space wird nur der Single GPU Passthrough-Modus (SPT) unterstützt. Der Wert ist also immer SPT. Weitere Informationen zur Unterstützung von NVIDIA Confidential Computing finden Sie im PDF zu NVIDIA Trusted Computing Solutions. Beispiel assertion.submods.nvidia_gpu.cc_feature == "SPT"
assertion.submods.nvidia_gpu.cc_mode Interagiert mit: Arbeitslastoperator: Die Metadatenvariable tee-install-gpu-driver.	Aufzählung	Prüft den Status des Confidential Computing-Treibers von NVIDIA. Die gültigen Werte sind: OFF: Keine der NVIDIA Confidential Computing-Funktionen ist aktiv. ON: Die Hardware, Firmware und Software von NVIDIA H100 haben die Confidential Computing-Funktionen vollständig aktiviert. DEVTOOLS: Die GPU befindet sich in einem partiellen vertraulichen Computing-Modus, der den Arbeitsabläufen des ON-Modus entspricht, aber Sicherheitsfunktionen deaktiviert. Beispiel assertion.submods.nvidia_gpu.cc_mode == "ON"
assertion.submods.nvidia_gpu.gpus Interagiert mit: Arbeitslastoperator: Die Metadatenvariable tee-install-gpu-driver.	Array von Objekten	Überprüft Behauptungen für jede bestätigte NVIDIA-GPU. Confidential Space unterstützt nur einen GPU-Anspruch. Ein gpus-Objekt sieht etwa so aus: { "hwmodel": "GCP_NVIDIA_H100", "ueid": "490457405999046854973671575630853621547794591064", "l4_serial_number": "1216669666319372030078", "driver_version": "570.00", "vbios_version": "96.00.9F.00.01" } Beispiele Mit dem folgenden Code wird geprüft, ob das erste GPU-Hardwaremodell eine NVIDIA H100 ist, die auf Google Cloudausgeführt wird: assertion.submods.nvidia_gpu.gpus[0].hwmodel == "GCP_NVIDIA_H100" Der folgende Code prüft, ob der Attestanspruch GPU-bezogene Ansprüche enthält: has(assertion.submods.nvidia_gpu.gpus)