Vertrauliche Ressourcen erstellen und Zugriff darauf gewähren

Datenmitwirkende

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

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

• Einen Workload Identity-Pool (WIP) zum Autorisieren der Arbeitslast. Nachdem eine Arbeitslast von einem WIP autorisiert wurde, kann sie auf die vertraulichen 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 den einzelnen Datenmitarbeitern gehören.

Hinweis: Wenn die Ressourcen des Datenmitarbeiters nicht von Google CloudIAM verwaltet werden, kann der Zugriff auf diese Ressourcen durch Anfordern von Attestierungstokens mit benutzerdefinierten Zielgruppen und optionalen Nonces verwaltet werden. Wenden Sie sich an den Ersteller der Arbeitslast, um dies zu implementieren. Weitere Informationen finden Sie unter Auf Ressourcen zugreifen, die nicht von Google Cloud IAM verwaltet werden.

Verschlüsselte Daten speichern

Sie können jeden Google Cloud -Dienst, der Daten speichert, zum Hosten Ihrer vertraulichen Daten verwenden. 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 sind, entweder mit integrierten Funktionen oder mit einem Dienst wie Cloud Key Management Service (Cloud KMS).

Achtung: Verwenden Sie beim Testen einer Arbeitslast mit Daten keine privaten Informationen. Richten Sie fiktive Daten im selben Format ein und testen Sie damit, bis Sie die Arbeitslast sperren können.

Arbeitslast mit einem WIP autorisieren

Ein WIP ist der Mechanismus, mit dem Confidential Space einer externen Arbeitslast ermöglicht, als föderierte Identität auf Ihre vertraulichen Daten zuzugreifen und damit zu arbeiten. Eine föderierte Identität ist eine externe Entität, die wie ein Hauptkonto in Ihrem eigenen Projekt behandelt wird. Sie können ihr IAM-Rollen zuweisen, um Zugriff auf bestimmte Ressourcen zu gewähren, oder die Identität von Dienstkonten übernehmen, um dasselbe zu tun.

Als Datenmitarbeiter richten Sie einen Anbieter in einem WIP 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:

• Attestierungsdienst: Dieser Dienst prüft, ob die Arbeitslast eine Confidential VM-Instanz ist, und gibt schließlich 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 Zugriff gewährt wird.

• Attributzuordnungen: Attribute in Zugriffstokens des Security Token Service, die Assertions zugeordnet sind, die von der authentifizierenden Entität erstellt wurden – in diesem Fall die VM-Instanz, auf der die Arbeitslast ausgeführt wird. Assertions 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-Logs in Cloud Logging und zum Zuweisen von Rollen über IAM auf der Grundlage von Authentifizierungsentitäts-Assertions wie Workload-Image-Container-Digests verwendet. Weitere Informationen zu Attributzuordnungen

• Eine Attestierungsrichtlinie: Eine Reihe von Bedingungen, die authentifizierende Entitäten erfüllen müssen, um Zugriff zu erhalten, basierend auf den von ihnen gemachten Zusicherungen.

Wenn eine Arbeitslast gestartet wird, sendet der Confidential Space Launcher seinen Attestierungsbericht an einen vom Arbeitslastoperator definierten Attestierungsdienst, der die Confidential VM-Instanz verifiziert und dann ein OIDC-Attestierungstoken zurückgibt. Dieses Token ist eine Stunde 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 ja, erhält die Arbeitslast Zugriff auf die vertraulichen Ressourcen.

Hinweis: Anstatt die Server von Google für die Tokenvalidierung zu verwenden, können Sie Attestierungstokens selbst mit langfristigen Zertifikaten validieren.

Zugriff auf externe Arbeitslasten

Bevor Sie einen WIP und einen Anbieter einrichten, müssen Sie festlegen, wie die Arbeitslast auf Ihre Ressourcen zugreifen soll: direkter Ressourcenzugriff oder Identitätsübernahme 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, der an die Assertions einer authentifizierenden Entität gebunden ist. So kann eine Arbeitslast basierend auf Attributen wie dem Container-Image-Digest der Arbeitslast autorisiert werden, direkt über IAM-Bindungen auf Ressourcen zuzugreifen.

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 Arbeitslastdienstkonto imitiert werden können.

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

• Jeder Ressourcenzugriff wird mit der föderierten Identität einer Arbeitslast-VM-Instanz protokolliert, anstatt mit der Identität eines Dienstkontos, die möglicherweise von mehreren Arbeitslasten gemeinsam genutzt wird. Die Identität einer Arbeitslast-VM-Instanz kann Details wie den Image-Digest eines Containers, die Projektnummer, von der aus die Arbeitslast ausgeführt wird, und die ID der VM-Instanz enthalten, auf der die Arbeitslast ausgeführt wird. Dies ermöglicht einen detaillierteren Audit-Trail.

• Sie müssen das VM-Instanzattribut selfLink 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 des Dienstkontos richtet jeder Datenmitarbeiter ein Dienstkonto ein, um seine privaten Daten zu entschlüsseln, und hängt dieses Dienstkonto dann an seinen eigenen WIP an. Außerdem geben sie das Dienstkonto für die Arbeitslast in ihrem WIP-Anbieter an. Dadurch kann das Dienstkonto für die Arbeitslast die Identität der Dienstkonten der Datenmitarbeiter übernehmen, um deren vertrauliche Daten abzurufen und zu verarbeiten.

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

• Wenn Sie Image-Signaturen als Authentifizierungsdaten 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 Identitätsübernahme des Dienstkontos kann möglicherweise nicht bei einem WIP-Anbieter authentifiziert werden, wenn eine VM-Instanz ein sehr langes selfLink-Attribut hat. Das liegt daran, dass die sub-Anforderung im Attestierungstoken, die auf den Wert selfLink festgelegt ist, im WIP-Anbieter dem Attribut google.subject zugeordnet wird, das ein Limit von 127 Byte hat.

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

WIP und Anbieter einrichten

Die Schritte zum Einrichten eines Anbieters hängen davon ab, ob Sie den direkten Ressourcenzugriff oder die Identitätsübernahme des Dienstkontos verwenden.

Direkter Ressourcenzugriff

Bei der Methode für den direkten Ressourcenzugriff werden ein WIP und ein Anbieter eingerichtet und dann IAM-Rollen basierend auf einem bestimmten Digest des Container-Images der Arbeitslast eingerichtet.

WIP und Anbieter einrichten

So richten Sie einen WIP und einen Anbieter ein:

1. Erstellen Sie den WIP:

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

2. Erstellen Sie einen OIDC-Anbieter im WIP:

   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:

   • Eine issuer-uri, die dem von Ihnen verwendeten Attestierungsdienst entspricht:

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

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

   • 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 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. Die folgenden Werte werden dem Attribut gcpcs zugewiesen und in Cloud Logging angezeigt, wenn die Arbeitslast auf Ressourcen zugreift:

     • assertion.submods.container.image_digest: Der Digest des Arbeitslast-Container-Images.

     • 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 Image-Digest des Arbeitslastcontainers, festgelegt. Dieses Attribut wird zugeordnet, damit Sie der föderierten Identität IAM-Rollen basierend auf einem bestimmten Image-Digest zuweisen können.

     Sie können alle verfügbaren Assertions für Arbeitslasten zuordnen, solange die Gesamtlänge des google.subject-Werts weniger als 127 Byte beträgt.

   • Die folgenden attribute-conditions, die eine Attestierungsrichtlinie bilden. Wenn diese Bedingungen mit den Assertions 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: Verifiziert, dass das Confidential Space-Produktions-Image verwendet wird und das Support-Attribut STABLE hat.

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

Der föderierten Identität IAM-Rollen zuweisen

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 gewährt:

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 zur Identitätsübernahme des Dienstkontos umfasst Folgendes:

1. Erstellen von Dienstkonten in jedem der Datenmitarbeiterprojekte und Gewähren der Berechtigung zum Entschlüsseln der vertraulichen Daten.

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

3. Erstellen Sie in jedem WIP WIP-Anbieter, die das Dienstkonto der Arbeitslast als das Konto angeben, 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. Beispielsweise können Sie vertrauliche Dateien in Cloud Storage mit Cloud KMS verschlüsseln. In diesem Fall 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

Führen Sie die folgenden Schritte in jedem Datenmitarbeiterprojekt aus, um einen WIP und einen Anbieter einzurichten:

1. Erstellen Sie den WIP:

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

2. Hängen Sie das Dienstkonto, das die Identität des WIP übernehmen soll, mit der Rolle roles/iam.workloadIdentityUser an den WIP an:

   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 darin das Dienstkonto für die Arbeitslast, damit es die Identität des Dienstkontos des Datenmitarbeiters ü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:

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

   • 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 in der sub-Anforderung im Attestierungstoken definiert.

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

   • Die folgenden attribute-conditions, die eine Attestierungsrichtlinie bilden. Wenn diese Bedingungen mit den Assertions 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 Workload-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 an die Arbeitslast angehängte Dienstkonto mit dem erwarteten Dienstkonto übereinstimmt, und verwendet es dann, um die Identität des Dienstkontos des Datenmitarbeiters 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: Verifiziert, dass das Confidential Space-Produktions-Image verwendet wird und das Support-Attribut STABLE hat.

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

Attestierungsrichtlinie erstellen

Im Rahmen der Erstellung eines WIP müssen Sie eine Attestierungsrichtlinie erstellen. Die Assertions einer authentifizierenden Entität müssen mit Ihrer Richtlinie übereinstimmen, damit sie auf Ihre Daten zugreifen 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.

Die Anweisungen verwenden Assertions aus dem Confidential Space-Image, dem Arbeitslast-Container-Image oder der VM-Instanz als Variablen und den von Ihnen angegebenen Wert als Ausdruck. Hier ist beispielsweise eine Richtlinie, die erzwingt, dass die Arbeitslast Confidential Space verwendet, ein STABLE Confidential Space-Image verwenden muss und dass die Zone, in der die Arbeitslast-VM-Instanz 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 Attestierungs-Assertions.

Attestierungs-Assertions

Die verfügbaren Assertions zum Erstellen einer Attestierungsrichtlinie 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 erstellt wurden.

Image-Assertions

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. Folgende Werte sind gültig: enable: Prüfen Sie, ob das Debug-Image verwendet wird. disabled-since-boot: Prüfen, ob das Produktions-Image verwendet wird. Beispiele Mit dem folgenden Code wird geprüft, ob die Debugging-Version des Confidential Space-Images verwendet wird: assertion.dbgstat == "enable" Mit dem folgenden Code wird geprüft, ob die Produktionsversion des Confidential Space-Images verwendet wird: assertion.dbgstat == "disabled-since-boot"
assertion.submods.confidential_space.support_attributes	Stringarray	Prüft, ob die Sicherheitsversion des TEE ein Confidential Space-Produktions-Image ist. Für Confidential Space-Debug-Images ist kein Support-Attribut festgelegt. In der folgenden Tabelle werden die Support-Attribute für Confidential Space-Produktions-Images beschrieben. Support-Attribut Beschreibung LATEST LATEST-Images haben außerdem die folgenden Support-Attribute: STABLE USABLE Lebensdauer des Bildes: Ungefähr ein Monat. Danach wird das Support-Attribut LATEST entfernt. Dies ist die aktuelle Version des Confidential Space-Images. Sie wird unterstützt und auf Sicherheitslücken überwacht. Für Arbeitslasten mit langer Ausführungszeit empfehlen wir, LATEST nicht als Teil Ihrer Attestierungsrichtlinie anzugeben. Das liegt daran, dass das Confidential Space-Image möglicherweise aktualisiert wird, während Ihre Arbeitslast ausgeführt wird. Dadurch ist das von Ihnen verwendete Confidential Space-Image nicht mehr LATEST und Ihre Arbeitslast schlägt bei der Attestierung fehl, wenn das Confidential Space-Standardtoken das nächste Mal aktualisiert wird. STABLE STABLE-Images haben außerdem die folgenden Support-Attribute: USABLE Lebensdauer des Images: Ungefähr sechs Monate. Ab dem 1. April 2027 wird das Support-Attribut STABLE nach Ablauf der Image-Lebensdauer entfernt. Images mit dem Attribut STABLE werden sechs Monate lang unterstützt und auf Sicherheitslücken überwacht. Wir empfehlen, die Attestierungsrichtlinie auf Grundlage des Attributs STABLE zu schreiben. In seltenen Fällen kann das Attribut STABLE während des normalen sechsmonatigen Supportzeitraums entfernt werden, z. B. wenn kritische Sicherheitslücken entdeckt werden. USABLE Images, die nur das Attribut USABLE haben, können weiterhin verwendet werden, gelten aber als veraltet. Verworfene Images werden nicht unterstützt und sind älter als sechs Monate. Die Nutzung erfolgt auf eigenes Risiko. USABLE-Images haben das Attribut deprecated.deprecated. Der Wert ist der Zeitstempel, zu dem das Image voraussichtlich verworfen wird. Die Attribute eines Images können mit dem Befehl gcloud compute images describe oder der REST-Methode images.get angezeigt werden. Beispiel: gcloud compute images describe confidential-space-240800 \ --format=json \ --project=confidential-space-images EXPERIMENTAL Images, die nur dieses Attribut haben, verwenden Funktionen in der Vorabversion. EXPERIMENTAL-Images sind nur für Testzwecke gedacht und sollten niemals in der Produktion verwendet werden. Ein EXPERIMENTAL-Image hat nie die Attribute LATEST, STABLE oder USABLE. Wir empfehlen, Ihr Confidential Space-Image auf dem neuesten Stand zu halten. Informationen zum Aktualisieren Ihres Confidential Space-Images finden Sie unter Confidential Space-Images aktualisieren. Wichtig: Confidential Space-Images können aufgrund von Ereignissen wie der Entdeckung kritischer Sicherheitslücken widerrufen werden. Wenn ein Image widerrufen wird, wird die swname-Anforderung im Attestierungstoken auf GCE gesetzt oder Ihre Arbeitslast erhält eine RIMS_VALIDATION_FAILED-Nachricht, wenn das Token angefordert wird. Beispiel Mit dem folgenden Code wird geprü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	Stringarray	Verifiziert die Softwareversion des Confidential Space-Images. Wir empfehlen, stattdessen assertion.submods.confidential_space.support_attributes zu verwenden, um die aktuelle Version eines Images anzusprechen. Beispiel int(assertion.swversion[0]) == 230103

Container-Assertions

Assertion	Typ	Beschreibung
assertion.submods.container.cmd_override Interagiert mit: Arbeitslastautor: Die Startrichtlinie allow_cmd_override. Arbeitslastoperator: Die Metadatenvariable tee-cmd.	Stringarray	Verifiziert die CMD-Befehle und -Parameter, die im Arbeitslast-Image verwendet werden. Beispiele Mit dem folgenden Code wird geprüft, ob der CMD des Arbeitslast-Images nicht überschrieben wurde: size(assertion.submods.container.cmd_override) == 0 Mit dem folgenden Code wird geprü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 Startrichtlinie allow_env_override. Arbeitslastoperator: Die Metadatenvariable tee-env-ENVIRONMENT_VARIABLE_NAME .	JSON-Objekt	Verifiziert, dass Umgebungsvariablen und deren Werte explizit an den Container übergeben wurden. Beispiel Mit dem folgenden Code wird geprüft, ob die Umgebungsvariable example-env-1 auf value-1 und example-env-2 auf value-2 gesetzt ist. assertion.submods.container.env == {"example-env-1": "value-1", "example-env-2": "value-2"}
assertion.submods.container.env_override Interagiert mit: Arbeitslastautor: Die Startrichtlinie allow_env_override. Arbeitslastoperator: Die Metadatenvariable tee-env-ENVIRONMENT_VARIABLE_NAME .	String	Prüft, ob der Arbeitslastoperator Umgebungsvariablen im Container überschrieben hat. Beispiele Mit dem folgenden Code wird geprüft, ob der Arbeitslastoperator die Umgebungsvariable example überschrieben hat: !has(assertion.submods.container.env_override.example) Mit dem folgenden Code wird geprü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 über eine Nutzlast, die mit dem signierten Container verknüpft ist und dem einfachen Signaturformat folgt. signature_algorithm: Der zum Signieren des Schlüssels verwendete Algorithmus. 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	Prüft die Neustart-Richtlinie des Container-Launchers, wenn die Arbeitslast beendet wird. Folgende Werte sind gültig: Never (Standard) Always OnFailure Beispiel assertion.submods.container.restart_policy == "Never"

VM-Assertions

Assertion	Typ	Beschreibung
assertion.google_service_accounts Interagiert mit: Arbeitslastoperator: Die Metadatenvariable tee-impersonate-service-accounts und der Wert --service-account .	Stringarray	Prüft, ob ein bestimmtes Dienstkonto mit der VM verbunden ist, auf der die Arbeitslast ausgeführt wird, oder mit tee-impersonate-service-accounts in den VM-Metadaten aufgelistet 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 Startrichtlinie monitoring_memory_allow. Arbeitslastoperator: Die Metadatenvariable tee-monitoring-memory-enable.	Boolesch	Prüft den Monitoringstatus auf der attestierenden Entität. Beispiel assertion.submods.confidential_space.monitoring_enabled.memory == true
assertion.submods.gce.instance_id	String	Verifiziert die VM-Instanz-ID. Beispiel assertion.submods.gce.instance_id == "0000000000000000000"
assertion.submods.gce.instance_name	String	Verifiziert 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-Features. In Confidential Space wird nur der SPT-Modus (Single GPU Passthrough) unterstützt. Der Wert ist also immer SPT. Weitere Informationen zur Unterstützung von NVIDIA Confidential Computing finden Sie unter NVIDIA Trusted Computing Solutions (PDF). 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. Folgende Werte sind gültig: OFF: Keine der NVIDIA Confidential Computing-Funktionen ist aktiv. ON: Die Confidential Computing-Funktionen wurden für die NVIDIA H100-Hardware, ‑Firmware und ‑Software vollständig aktiviert. DEVTOOLS: Die GPU befindet sich in einem partiellen Confidential Computing-Modus, der den Workflows des ON-Modus entspricht, aber die Sicherheitsmaßnahmen deaktiviert. Beispiel assertion.submods.nvidia_gpu.cc_mode == "ON"
assertion.submods.nvidia_gpu.gpus Interagiert mit: Arbeitslastoperator: Die Metadatenvariable tee-install-gpu-driver.	Objekt-Array	Prüft die Ansprüche für jede attestierte NVIDIA-GPU. Confidential Space unterstützt nur eine einzelne GPU-Anforderung. Ein gpus-Objekt sieht in 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" Mit dem folgenden Code wird geprüft, ob die Attestierungsforderung GPU-bezogene Anforderungen enthält: has(assertion.submods.nvidia_gpu.gpus)