Vertrauliche Ressourcen erstellen und Zugriff darauf gewähren

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 sollen und ob diese Ergebnisse für jeden Mitwirkenden eindeutig sind oder geteilt werden. Sie können beispielsweise dasselbe Ergebnis in mehrere Cloud Storage-Buckets ausgeben, die zu den einzelnen Datenpartnern gehören.

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:

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).

Arbeitslast mit einer WIP autorisieren

Ein WIP ist der Mechanismus, mit dem Confidential Space einer externen Arbeitslast den Zugriff auf Ihre vertraulichen Daten als zusammengeführte Identität ermöglicht. Eine föderierte Identität ist eine externe Einheit, die so behandelt wird, als wäre sie ein Hauptkonto in Ihrem eigenen Projekt. So können Sie ihr IAM-Rollen zuweisen, um Zugriff auf bestimmte Ressourcen zu gewähren oder Dienstkonten zu imitieren, 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 Verbundidentitä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 Security Token Service-Zugriffstokens, die Bestätigungen zugeordnet sind, die von der authentifizierenden Identität vorgenommen werden. In diesem Fall ist das 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 unter anderem für Prüfpfade in Cloud Logging verwendet und um Rollen über IAM auf Grundlage von Authentifizierungsentitätszusicherungen wie Arbeitslastbild-Container-Digests zu gewähren. Weitere Informationen zu Attributzuordnungen

  • Eine Attestierungsrichtlinie: Eine Reihe von Bedingungen, die authentifizierende Einheiten erfüllen müssen, um auf der 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 prü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.

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ä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 einer Arbeitslast der Zugriff auf Ressourcen direkt über IAM-Bindungen autorisiert werden, 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 für ein Workload-Dienstkonto einrichten müssen, das imitiert werden soll.

  • 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 Arbeitslast-VM-Instanz protokolliert, anstatt mit der Identität eines imitierten Dienstkontos, das 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, unter 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 google.subject-Attribut 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übertragung für ein Dienstkonto

Bei der Methode zur Identitätsübernahme für Dienstkonten richtet jeder Datenpartner ein Dienstkonto zum Entschlüsseln seiner privaten Daten ein und hängt dieses Dienstkonto dann an seinen eigenen Arbeitsbereich an. Sie geben auch das Dienstkonto der Arbeitslast in ihrem WIP-Anbieter an. Dadurch kann das Dienstkonto der Arbeitslast die Identität der Dienstkonten der Datenmitarbeiter übernehmen, um ihre vertraulichen Daten abzurufen und zu verarbeiten.

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

Die Methode zur Übernahme der Identität eines Dienstkontos kann bei der Authentifizierung bei einem WIP-Anbieter fehlschlagen, wenn eine VM-Instanz eine sehr lange selfLink-Eigenschaft hat. Das liegt daran, dass die sub-Anforderung im Attestierungstoken, die auf den selfLink-Wert festgelegt ist, im WIP-Anbieter dem Attribut google.subject 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 einen WIP und einen Anbieter ein:

  1. WIP erstellen:

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

  2. So 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="https://confidentialcomputing.googleapis.com/" \
    --allowed-audiences="https://sts.googleapis.com" \
    --attribute-mapping="google.subject=\"gcpcs::\"+assertion.submods.container.image_digest+\"::\"+assertion.submods.gce.project_number+\"::\"+assertion.submods.gce.instance_id,attribute.image_digest=assertion.submods.container.image_digest" \
    --attribute-condition="assertion.swname == 'CONFIDENTIAL_SPACE' \
        && 'STABLE' in assertion.submods.confidential_space.support_attributes"

    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.

    • 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 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 der 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 festgelegt, den Image-Digest des Arbeitslastcontainers. 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 beliebige der verfügbaren Arbeitslast-Assertions zuordnen, sofern 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 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 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übertragung für ein Dienstkonto

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 Datenkooperationspartner 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 den 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:

    • Ein 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 Bestätigungstoken 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 Arbeitslastcontainer-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 an die Arbeitslast angehängt 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:

 Definierter String

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, ob die Sicherheitsversion des TEE ein Confidential Space-Produktions-Image ist. Für Debug-Images im Confidential Space ist kein Attribut „support“ festgelegt.

Es gibt drei Supportattribute:

  • 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. Es ist nur für Testzwecke vorgesehen und sollte niemals in der Produktion verwendet werden. Ein EXPERIMENTAL-Bild hat nie die Attribute LATEST, STABLE oder USABLE.
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 Definierter String

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 auf die aktuelle Version eines Bildes auszurichten.

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

Container-Assertions

Assertion Typ Beschreibung

assertion.submods.container.cmd_override

Interagiert mit:

 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 ü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:

 JSON-Objekt

Wird verwendet, um zu verifizieren, 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:

 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:

 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:

 JSON-Objekt

Prüft, ob das Bild 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 -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
assertion.swname == 'CONFIDENTIAL_SPACE' && ['ECDSA_P256_SHA256:PUBLIC_KEY_FINGERPRINT'].exists(fingerprint, fingerprint in assertion.submods.container.image_signatures.map(sig, sig.signature_algorithm+':'+sig.key_id)) && 'serviceaccount.iam.gserviceaccount.com' in assertion.google_service_accounts"

assertion.submods.container.restart_policy

Interagiert mit:

 Definierter String

Ü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:

 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
workload-service-account@my-project.iam.gserviceaccount.com 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:

 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_mode

Interagiert mit:

 Definierter String

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 Funktionen für vertrauliches Computing 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"