Vertrauliche Ressourcen erstellen und Zugriff darauf gewähren

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

Außerdem müssen Datenmitwirkende auswählen, wo die Ergebnisse der Confidential Space-Arbeitslast gespeichert werden und ob die präsentierten Daten eindeutig oder gemeinsam genutzt werden. Sie könnten beispielsweise dasselbe Ergebnis in mehrere Cloud Storage-Buckets ausgeben, die zu den einzelnen Datenmitarbeitern gehören.

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

Dienstkonto zum Entschlüsseln vertraulicher Daten erstellen

Sie stellen Ihre vertraulichen Daten für Confidential Space-Arbeitslasten zur Verfügung und verringern den Zugriff von Menschen auf diese Daten über Dienstkonten.

Sie können beispielsweise vertrauliche Dateien in Cloud Storage mit Cloud KMS verschlüsseln und dann ein Dienstkonto erstellen, das die Berechtigung hat, auf diese Daten und den Schlüssel zum Entschlüsseln zuzugreifen.

Anschließend verknüpfen Sie das Dienstkonto mit einem WIP. Eine autorisierte Confidential Space-Arbeitslast in einem anderen Projekt kann dann dieses WIP verwenden, um die Identität des Dienstkontos zu übernehmen, das die Daten entschlüsselt, die entschlüsselten Daten abzurufen und sie zu verarbeiten.

Da Dienstkonten sowohl zum Entschlüsseln als auch zum Verarbeiten dieser vertraulichen Daten verwendet werden, ist die Sichtbarkeit der Daten auf ihre Inhaber beschränkt. Da die Arbeitslast in einer Confidential VM ausgeführt wird, sorgt die hardwarebasierte Speicherverschlüsselung dafür, dass Ihre Daten während der Nutzung privat bleiben. SSH ist auch auf Arbeitslast-VMs deaktiviert, die das Confidential Space-Produktionsimage verwenden. Das bedeutet, dass niemand auf die VM zugreifen kann, während sie ausgeführt wird.

Ein Beispiel dafür finden Sie unter Erste Confidential Space-Umgebung erstellen.

Workload Identity-Pool und -Anbieter für die Attestierungsvalidierung erstellen

Zum Schutz von Daten vor einem nicht vertrauenswürdigen Arbeitslastoperator implementiert Confidential Space einen Attestierungsprozess, der Änderungen an einem Arbeitslast-Image oder seiner TEE erkennt. Der Prozess beruht auf Shielded VM-Messungen von Measured Boot und erweiterten Laufzeiten und erfasst Messungen der Startsequenz in einem geschützten "extend-only"-Register im vTPM-Gerät (virtual Trusted Platform Module).

Der Attestierungsdienst von Confidential Space generiert OpenID Connect-Tokens (OIDC), die diese vTPM-Attestierungen in einer Form enthalten, die von einem WIP validiert werden kann. Dabei werden sie anhand von Richtlinien geprüft, die als Attributbedingungen zu einem Anbieter hinzugefügt werden. Diese Tokens werden von Google signiert, sind eine Stunde gültig und werden automatisch aktualisiert.

Wenn die WIP die Arbeitslast autorisiert, kann die Arbeitslast dann Dienstkonten im Projekt übernehmen, um vertrauliche Daten zu entschlüsseln und abzurufen.

So richten Sie einen WIP und einen Anbieter ein:

  1. Erstellen Sie den WIP.

  2. Verknüpfen Sie Ihr Dienstkonto für die Entschlüsselung mit dem WIP und weisen Sie ihm die Rolle iam.workloadIdentityUser zu.

  3. Erstellen Sie einen OIDC-Anbieter mit den folgenden Details:

    • Ein Aussteller-URI von https://confidentialcomputing.googleapis.com/.

    • Eine zulässige Zielgruppe von https://sts.googleapis.com.

    • Eine Anbieterattributzuordnung von google.subject mit dem Wert assertion.sub.

    • Attributbedingungen, die zum Validieren der Attestierungen der Arbeitslast verwendet werden. Informationen zu den verfügbaren Optionen finden Sie unter Attestierungsrichtlinie erstellen.

Attestierungsrichtlinie erstellen

Beim Erstellen eines WIP fügen Sie Attributbedingungen hinzu. Das sind Bedingungen, die ein Arbeitslast durchlaufen muss, um auf Ihre Daten zugreifen zu können. Für Confidential Space bilden diese Attributbedingungen Ihre Attestierungsrichtlinie.

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

Im Folgenden finden Sie ein Beispiel für das Hinzufügen eines Anbieters zu einem Workload Identity-Pool mithilfe der gcloud CLI zusammen mit der Option attribute-condition, die die Richtlinien definiert:

gcloud iam workload-identity-pools providers create-oidc attestation-verifier \
    --location=global \
    --workload-identity-pool=user-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 =='sha256:837ccb607e312b170fac7383d7ccfd61fa5072793f19a25e75fbacb56539b86b' \
&& 'service-account@my-project.iam.gserviceaccount.com' in assertion.google_service_accounts \
&& assertion.swname == 'CONFIDENTIAL_SPACE' \
&& 'STABLE' in assertion.submods.confidential_space.support_attributes"

In diesem Beispiel muss eine externe Identität, die versucht, die Identität eines Dienstkontos zu übernehmen, das mit dem Workload Identity-Pool verbunden ist, die folgenden Details attestieren und abgleichen:

  • Den Image-Digest des Arbeitslastcontainers

  • Die Adresse des Dienstkontos, das mit der VM für die Arbeitslast verbunden ist

  • CONFIDENTIAL_SPACE ist die Software, die auf der VM ausgeführt wird, mit allen integrierten Sicherheitsgarantien.

  • Das Attribut „support“ für das Confidential Space-Produktions-Image

Attestierungs-Assertions

Die verfügbaren Zusicherungen zum Erstellen einer Attestrichtlinie sind in der folgenden Tabelle aufgeführt. Sie können Assertions validieren, die vom Confidential Space-Image, vom Arbeitslastcontainer und von der VM 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.
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 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 -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"