Mit Confidential Space geschützte freigegebene Daten schützen

1. Übersicht

Confidential Space bietet eine sichere Freigabe und Zusammenarbeit mit mehreren Parteien und ermöglicht es Organisationen, die Vertraulichkeit ihrer Daten zu wahren. So können Organisationen zusammenarbeiten und gleichzeitig die Kontrolle über ihre Daten behalten und sie vor unbefugtem Zugriff schützen.

Mit Confidential Space können Sie Szenarien nutzen, in denen Sie durch die Zusammenführung und Analyse sensibler, oft regulierter Daten einen gemeinsamen Nutzen erzielen und gleichzeitig die volle Kontrolle darüber behalten. Mit Confidential Space können Organisationen gegenseitigen Nutzen aus der Zusammenführung und Analyse sensibler Daten wie personenidentifizierbarer Informationen (PII), geschützter Gesundheitsdaten (PHI), geistigen Eigentums und kryptografischer Geheimnisse ziehen und dabei die volle Kontrolle darüber behalten.

Voraussetzungen

• Google Cloud Platform-Projekt
• Browser, z. B. Chrome oder Firefox
• Grundlegende Kenntnisse der Google Compute Engine ( Codelab), Confidential VMs, Container und Remote-Repositories
• Grundlegende Kenntnisse zu Cloud KMS ( Codelab)
• Grundlegende Kenntnisse zu Dienstkonten, Workload Identity-Föderation und Attributbedingungen

Aufgaben in diesem Lab

• Erforderliche Cloud-Ressourcen für den Betrieb von vertraulichen Gruppenbereichen konfigurieren
• Arbeitslast in einer Confidential VM ausführen, auf der das VM-Image für Confidential Space ausgeführt wird
• So autorisieren Sie den Zugriff auf geschützte Ressourcen basierend auf den Attributen des Arbeitslastcodes (what), der Confidential Space-Umgebung (where) und des Kontos, in dem die Arbeitslast ausgeführt wird (who).

In diesem Codelab richten Sie einen vertraulichen Bereich zwischen der Primus- und der Secundus-Bank ein, um ihre gemeinsamen Kunden zu ermitteln, ohne vollständige Kontolisten miteinander zu teilen. Dazu sind folgende Schritte erforderlich:

• Schritt 1: Erforderliche Cloud-Ressourcen für Primus und Secundus Bank einrichten Zu diesen Cloud-Ressourcen gehören Cloud Storage-Buckets, KMS-Schlüssel, Workload Identity-Pools und Dienstkonten für Primus und Secundus Bank. Die Primus-Bank und die Secundus-Bank speichern ihre Kundendaten in Cloud Storage-Buckets und verschlüsseln sie mit Cloud Key Management Service-Schlüsseln.
• Schritt 2: Dienstkonto für die Arbeitslast erstellen, das von der Arbeitslast-VM verwendet wird. Die Secundus Bank, die die Arbeitslast betreibt, startet die Arbeitslast-VM. Primus Bank würde den Code für die Arbeitslast erstellen.
• Schritt 3: Erstellen Sie eine Arbeitslast mit zwei Befehlszeilen, einen zum Zählen der Kunden am angegebenen Standort und einen zum Finden gemeinsamer Kunden der Primus- und Secundus-Bank. Die Arbeitslast wird von Primus Bank erstellt und als Docker-Image verpackt. Dieses Docker-Image wird in Artifact Registry veröffentlicht.
• Schritt 4: Arbeitslast autorisieren Die Primus Bank würde einen Workload Identity-Pool verwenden, um Arbeitslasten basierend auf den Attributen zu autorisieren, wer die Arbeitslast ausführt, was die Arbeitslast tut und wo die Arbeitslast ausgeführt wird.
• Schritt 5: Wenn die Arbeitslast ausgeführt wird, wird der Zugriff auf die Cloud-Ressourcen der Datenbearbeiter (Primus Bank und Secundus Bank) angefordert, indem ein Attestation Verifier Service-Token mit Arbeitslast- und Umgebungsansprüchen angeboten wird. Wenn die Arbeitslastmessansprüche im Token mit der Attributbedingung in den Workload Identity-Pools von Primus und Secundus Bank übereinstimmen, wird das Dienstkonto-Zugriffstoken zurückgegeben, das zum Zugriff auf die jeweiligen Cloud-Ressourcen berechtigt ist. Auf die Cloud-Ressourcen kann nur die Arbeitslast zugreifen, die in Confidential Space ausgeführt wird.
• Schritt 5(a): Führen Sie die erste Arbeitslast aus, bei der Kunden der Primus Bank an bestimmten Standorten gezählt werden. Für diese Arbeitslast wäre die Primus Bank ein Datenbearbeiter und Arbeitslastautor, der die verschlüsselte Kundenliste der Arbeitslast zur Verfügung stellt, die in Confidential Space ausgeführt wird. Secundus Bank ist ein Arbeitslastoperator und führt die Arbeitslast in einem Confidential Space aus.
• Schritt 5(b): Führen Sie die zweite Arbeitslast aus, um die gemeinsamen Kunden der Primus- und Secundus-Banken zu ermitteln. Für diese Arbeitslast sind die Primus Bank und die Secundus Bank beide Datenbearbeiter. Sie stellen die verschlüsselten Kundenlisten der Arbeitslast zur Verfügung, die in Confidential Space ausgeführt wird. Secundus Bank wäre dann wieder ein Arbeitslast-Operator. Diese Arbeitslast würde auch von der Secundus Bank autorisiert, da sie zum Finden der gemeinsamen Kunden auch auf die verschlüsselten Kundenlisten der Secundus Bank zugreifen muss. In diesem Fall autorisiert die Secundus Bank die Arbeitslast, auf ihre Kundendaten zuzugreifen, basierend auf den Attributen, wer die Arbeitslast ausführt, was die Arbeitslast tut und wo die Arbeitslast ausgeführt wird, wie in Schritt 4 für die Primus Bank erwähnt.

2. Cloud-Ressourcen einrichten

Hinweis

• Klonen Sie dieses Repository mit dem folgenden Befehl, um die erforderlichen Scripts zu erhalten, die in diesem Codelab verwendet werden.

git clone https://github.com/GoogleCloudPlatform/confidential-space.git

• Wechseln Sie in das Verzeichnis für dieses Codelab.

cd confidential-space/codelabs/bank_data_analysis_codelab/scripts

• Achten Sie darauf, dass Sie die erforderlichen Projektumgebungsvariablen wie unten gezeigt festgelegt haben. Weitere Informationen zum Erstellen eines GCP-Projekts finden Sie in diesem Codelab. In diesem Artikel finden Sie weitere Informationen dazu, wie Sie die Projekt-ID abrufen und wie sie sich von Projektnamen und Projektnummer unterscheidet.

export PRIMUS_PROJECT_ID=<GCP project id of Primus bank>
export SECUNDUS_PROJECT_ID=<GCP project id of Secundus bank>

• Aktivieren Sie die Abrechnung für Ihre Projekte.
• Aktivieren Sie die Confidential Computing API und die folgenden APIs für beide Projekte.

gcloud services enable \
    cloudapis.googleapis.com \
    cloudkms.googleapis.com \
    cloudresourcemanager.googleapis.com \
    cloudshell.googleapis.com \
    container.googleapis.com \
    containerregistry.googleapis.com \
    iam.googleapis.com \
    confidentialcomputing.googleapis.com

• Legen Sie mit diesem Befehl die Variablen für Ressourcennamen wie unten angegeben fest. Sie können die Ressourcennamen mithilfe dieser Variablen (z. B. export PRIMUS_INPUT_STORAGE_BUCKET='my-input-bucket') überschreiben.
• Sie können die folgenden Variablen mit vorhandenen Namen von Cloud-Ressourcen im Primus-Projekt festlegen. Wenn die Variable festgelegt ist, wird die entsprechende vorhandene Cloud-Ressource aus dem Primus-Projekt verwendet. Wenn die Variable nicht festgelegt ist, wird der Name der Cloud-Ressource aus dem Projektnamen generiert und eine neue Cloud-Ressource wird im Rahmen des folgenden Vorgangs erstellt:

$PRIMUS_INPUT_STORAGE_BUCKET	Der Bucket, in dem die Kundendatendatei der Primus Bank gespeichert ist.
$PRIMUS_WORKLOAD_IDENTITY_POOL	Der Workload Identity-Pool (WIP) der Primus Bank, der Ansprüche validiert.
$PRIMUS_WIP_PROVIDER	Der Workload Identity-Pool-Anbieter der Primus Bank, einschließlich der Autorisierungsbedingung für Tokens, die vom Attestation Verifier Service signiert wurden.
$PRIMUS_SERVICE_ACCOUNT	Das Dienstkonto der Primus Bank, das $PRIMUS_WORKLOAD_IDENTITY_POOL für den Zugriff auf die geschützten Ressourcen verwendet. In diesem Schritt hat es die Berechtigung, die Kundendaten aufzurufen, die im Bucket $PRIMUS_INPUT_STORAGE_BUCKET gespeichert sind.
$PRIMUS_ENC_KEY	Der KMS-Schlüssel, der zum Verschlüsseln der in $PRIMUS_INPUT_STORAGE_BUCKET für die Primus Bank gespeicherten Daten verwendet wird.
$PRIMUS_ENC_KEYRING	Der KMS-Schlüsselbund, mit dem der Verschlüsselungsschlüssel $PRIMUS_ENC_KEY für die Primus Bank erstellt wird.
$PRIMUS_ARTIFACT_REPOSITORY	Das Artifact-Repository, in das das Docker-Image der Arbeitslast gepusht wird.

• Sie können die folgenden Variablen mit vorhandenen Namen von Cloud-Ressourcen im Secundus-Projekt festlegen. Wenn die Variable festgelegt ist, wird die entsprechende vorhandene Cloud-Ressource aus dem Secundus-Projekt verwendet. Wenn die Variable nicht festgelegt ist, wird der Name der Cloud-Ressource aus dem Projektnamen generiert und eine neue Cloud-Ressource wird im Rahmen der folgenden Schritte erstellt:

$SECUNDUS_INPUT_STORAGE_BUCKET	Der Bucket, in dem die Kundendatendatei der Secundus Bank gespeichert ist
$SECUNDUS_WORKLOAD_IDENTITY_POOL	Der Workload Identity-Pool (WIP) der Secundus Bank, der Ansprüche validiert.
$SECUNDUS_WIP_PROVIDER	Der Workload Identity-Pool-Anbieter der Secundus Bank, der die Autorisierungsbedingung für vom Attestation Verifier Service signierte Tokens enthält.
$SECUNDUS_SERVICE_ACCOUNT	Das Dienstkonto der Secundus Bank, das $SECUNDUS_WORKLOAD_IDENTITY_POOL für den Zugriff auf die geschützten Ressourcen verwendet. In diesem Schritt hat es die Berechtigung, die Kundendaten aufzurufen, die im Bucket $SECUNDUS_INPUT_STORAGE_BUCKET gespeichert sind.
$SECUNDUS_ENC_KEY	Der KMS-Schlüssel, der zum Verschlüsseln der in $SECUNDUS_INPUT_STORAGE_BUCKET gespeicherten Daten für die Secundus Bank verwendet wird.
$SECUNDUS_ENC_KEYRING	Der KMS-Schlüsselbund, mit dem der Verschlüsselungsschlüssel $SECUNDUS_ENV_KEY für die Secundus Bank erstellt wird.
$SECUNDUS_RESULT_STORAGE_BUCKET	Der Bucket, in dem die Arbeitslastergebnisse gespeichert werden.
$WORKLOAD_IMAGE_NAME	Der Name des Arbeitslast-Container-Images.
$WORKLOAD_IMAGE_TAG	Das Tag des Arbeitslastcontainer-Images.
$WORKLOAD_SERVICE_ACCOUNT	Das Dienstkonto, das auf die vertrauliche VM zugreifen darf, auf der die Arbeitslast ausgeführt wird.

• Im Rahmen dieses Codelabs werden einige Artefakte verwendet, die unten aufgeführt sind:
• primus_customer_list.csv: Die Datei mit den Kundendaten der Primus Bank. Hier finden Sie die Beispieldatei, die in diesem Codelab verwendet wird.
• secundus_customer_list.csv: Die Datei, die die Kundendaten der Secundus Bank enthält. Hier finden Sie die Beispieldatei, die in diesem Codelab verwendet wird.
• Für diese beiden Projekte benötigen Sie bestimmte Berechtigungen:
• Für die $PRIMUS_PROJECT_ID benötigen Sie die Rollen „Cloud KMS-Administrator“, „Speicheradministrator“, „Artifact Registry Administrator“, „Dienstkontoadministrator“ und „IAM Workload Identity-Pooladministrator“.
• Für die $SECUNDUS_PROJECT_ID benötigen Sie die Rollen „Compute-Administrator“, „Speicheradministrator“, „Dienstkontoadministrator“, „Cloud KMS-Administrator“, „IAM-Workload Identity-Pooladministrator“ und „Sicherheitsadministrator“ (optional).
• Führen Sie das folgende Script aus, um die verbleibenden Variablennamen auf Werte basierend auf Ihrer Projekt-ID für Ressourcennamen festzulegen.

source config_env.sh

Cloud-Ressourcen für Primus Bank einrichten

Für die Primus Bank sind die folgenden Cloud-Ressourcen erforderlich. Führen Sie dieses Script aus, um die Ressourcen für die Primus Bank einzurichten:

• Cloud Storage-Bucket ($PRIMUS_INPUT_STORAGE_BUCKET) zum Speichern der verschlüsselten Kundendatendatei der Primus Bank.
• Verschlüsselungsschlüssel ($PRIMUS_ENC_KEY) und Schlüsselbund ($PRIMUS_ENC_KEYRING) in KMS zum Verschlüsseln der Kundendatendatei der Primus Bank.
• Workload Identity-Pool ($PRIMUS_WORKLOAD_IDENTITY_POOL) zur Validierung von Ansprüchen anhand von Attributbedingungen, die beim Anbieter konfiguriert wurden.
• Das Dienstkonto ($PRIMUS_SERVICE_ACCOUNT), das mit dem oben genannten Workload Identity-Pool ($PRIMUS_WORKLOAD_IDENTITY_POOL) verknüpft ist, hat Zugriff, um Daten mit dem KMS-Schlüssel zu entschlüsseln (Rolle roles/cloudkms.cryptoKeyDecrypter), Daten aus dem Cloud Storage-Bucket zu lesen (Rolle objectViewer) und das Dienstkonto mit dem Workload Identity-Pool zu verbinden (Rolle roles/iam.workloadIdentityUser).

./setup_primus_bank_resources.sh

Cloud-Ressourcen für die Secundus Bank einrichten

Für die Secundus Bank sind die folgenden Cloud-Ressourcen erforderlich. Führen Sie dieses Script aus, um die Ressourcen der Secundus Bank einzurichten. Im Rahmen dieser Schritte werden die folgenden Ressourcen erstellt:

• Cloud Storage-Bucket ($SECUNDUS_INPUT_STORAGE_BUCKET) zum Speichern der verschlüsselten Kundendatendatei der Secundus Bank.
• Verschlüsselungsschlüssel ($SECUNDUS_ENC_KEY) und Schlüsselbund ($SECUNDUS_ENC_KEYRING) in KMS zum Verschlüsseln der Datendatei der Secundus Bank.
• Workload Identity-Pool ($SECUNDUS_WORKLOAD_IDENTITY_POOL) zur Validierung von Ansprüchen anhand von Attributbedingungen, die beim Anbieter konfiguriert wurden.
• Das Dienstkonto ($SECUNDUS_SERVICE_ACCOUNT), das mit dem oben genannten Workload Identity Pool ($SECUNDUS_WORKLOAD_IDENTITY_POOL) verknüpft ist, hat Zugriff auf die Entschlüsselung von Daten mit dem KMS-Schlüssel (Rolle roles/cloudkms.cryptoKeyDecrypter), das Lesen von Daten aus dem Cloud Storage-Bucket (Rolle objectViewer) und die Verknüpfung des Dienstkontos mit dem Workload Identity Pool (Rolle roles/iam.workloadIdentityUser).
• Cloud Storage-Bucket ($SECUNDUS_RESULT_STORAGE_BUCKET) zum Speichern des Ergebnisses der Arbeitslastausführung durch die Secundus Bank.

./setup_secundus_bank_resources.sh

3. Arbeitslast erstellen

Dienstkonto für Arbeitslast erstellen

Jetzt erstellen Sie ein Dienstkonto für die Arbeitslast mit den unten genannten erforderlichen Rollen und Berechtigungen. Führen Sie das folgende Script aus, um ein Arbeitslastdienstkonto im Projekt „Secundus Bank“ zu erstellen. Die VM, auf der die Arbeitslast ausgeführt wird, verwendet dieses Dienstkonto.

Dieses Workload-Dienstkonto ($WORKLOAD_SERVICE_ACCOUNT) hat die folgenden Rollen:

• Weisen Sie dem Dienstkonto der Arbeitslast die Rolle confidentialcomputing.workloadUser zu . Dadurch kann das Nutzerkonto ein Attestierungstoken generieren.
• Weisen Sie dem Dienstkonto für die Arbeitslast die Rolle logging.logWriter zu. So können in der Confidential Space-Umgebung zusätzlich zur seriellen Konsole Logs in Cloud Logging geschrieben werden, sodass Logs auch nach dem Beenden der VM verfügbar sind.
• objectViewer, um Daten aus dem Cloud Storage-Bucket $PRIMUS_INPUT_STORAGE_BUCKET zu lesen.
• objectViewer, um Daten aus dem Cloud Storage-Bucket $SECUNDUS_INPUT_STORAGE_BUCKET zu lesen.
• objectAdmin, um das Arbeitslastergebnis in den Cloud Storage-Bucket $SECUNDUS_RESULT_STORAGE_BUCKET zu schreiben.

./create_workload_service_account.sh

Arbeitslast erstellen

In diesem Schritt erstellen Sie ein Docker-Image für die in diesem Codelab verwendete Arbeitslast. Die Arbeitslast ist eine einfache GoLang-Anwendung, die:

• Kunden in einem bestimmten geografischen Gebiet werden gezählt.
• Es werden gemeinsame Kunden der Primus- und Secundus-Bank anhand der Kundenlisten ermittelt, die in den jeweiligen Cloud Storage-Buckets gespeichert sind.

Führen Sie das folgende Script aus, um eine Arbeitslast zu erstellen, in der die folgenden Schritte ausgeführt werden:

• Erstellen Sie eine Artifact Registry ($PRIMUS_ARTIFACT_REPOSITORY) im Besitz der Primus Bank, in der die Arbeitslast veröffentlicht werden soll.
• Generieren Sie den Code und aktualisieren Sie ihn mit den erforderlichen Ressourcennamen. Den in diesem Codelab verwendeten Code für Arbeitslasten finden Sie hier.
• Erstellen Sie den Code und verpacken Sie ihn in einem Docker-Image. Das entsprechende Dockerfile finden Sie hier.
• Veröffentlichen Sie das Docker-Image in der Artifact Registry ($PRIMUS_ARTIFACT_REGISTRY) der Primus Bank.
• Gewähren Sie dem Dienstkonto $WORKLOAD_SERVICE_ACCOUNT die Leseberechtigung für Artifact Registry ($PRIMUS_ARTIFACT_REGISTRY).

./create_workload.sh

4. Arbeitslasten autorisieren und ausführen

Arbeitslast autorisieren

Die Primus Bank möchte Arbeitslasten basierend auf Attributen der folgenden Ressourcen für den Zugriff auf ihre Kundendaten autorisieren:

• Was: Code, der bestätigt wurde
• Wo: Eine sichere Umgebung
• Wer: Ein vertrauenswürdiger Betreiber

Primus verwendet die Workload Identity-Föderation, um eine Zugriffsrichtlinie auf der Grundlage dieser Anforderungen durchzusetzen.

Mit der Workload Identity-Föderation können Sie Attributbedingungen angeben. Mit diesen Bedingungen wird eingeschränkt, welche Identitäten sich beim Workload Identity-Pool (WIP) authentifizieren können. Sie können den Attestation Verifier Service dem WIP als Workload Identity-Pool-Anbieter hinzufügen, um Messungen vorzulegen und die Richtlinie durchzusetzen.

Der Workload Identity-Pool wurde bereits im Rahmen der Einrichtung der Cloud-Ressourcen erstellt. Jetzt erstellt die Primus Bank einen neuen OIDC-Workload Identity-Pool-Anbieter. Die angegebene --attribute-condition autorisiert den Zugriff auf den Arbeitslastcontainer. Dafür sind erforderlich:

• Was: Letzte $WORKLOAD_IMAGE_NAME, die in das $PRIMUS_ARTIFACT_REPOSITORY-Repository hochgeladen wurde.
• Wo: Die vertrauenswürdige Ausführungsumgebung von Confidential Space wird auf dem vollständig unterstützten VM-Image von Confidential Space ausgeführt.
• Wer: Dienstkonto der Secundus Bank $WORKLOAD_SERVICE_ACCOUNT.

gcloud config set project $PRIMUS_PROJECT_ID

gcloud iam workload-identity-pools providers create-oidc $PRIMUS_WIP_PROVIDER \
  --location="global" \
  --workload-identity-pool="$PRIMUS_WORKLOAD_IDENTITY_POOL" \
  --issuer-uri="https://confidentialcomputing.googleapis.com/" \
  --allowed-audiences="https://sts.googleapis.com" \
  --attribute-mapping="google.subject='assertion.sub'" \
  --attribute-condition="assertion.swname == 'CONFIDENTIAL_SPACE' && 
   'STABLE' in assertion.submods.confidential_space.support_attributes &&
   assertion.submods.container.image_reference == 'us-docker.pkg.dev/$PRIMUS_PROJECT_ID/$PRIMUS_ARTIFACT_REPOSITORY/$WORKLOAD_IMAGE_NAME:$WORKLOAD_IMAGE_TAG' && 
'$WORKLOAD_SERVICE_ACCOUNT@$SECUNDUS_PROJECT_ID.iam.gserviceaccount.com' in assertion.google_service_accounts"

Ähnlich wie bei der WIP, die für die Primus Bank erstellt wurde, möchte die Secundus Bank Arbeitslasten auf Grundlage der folgenden Kriterien autorisieren, auf ihre Kundendaten zuzugreifen:

• Was: Die Arbeitslast.
• Wo: In der Confidential Space-Umgebung.
• Wer: Das Konto ($WORKLOAD_SERVICE_ACCOUNT), in dem die Arbeitslast ausgeführt wird.

Die Primus Bank verwendet den image_reference-Anspruch, der das Bild-Tag enthält, um zu bestimmen, ob der Zugriff autorisiert werden soll. Sie verwalten das Remote-Repository und können so sicher sein, dass nur Bilder getaggt werden, die ihre Daten nicht preisgeben.

Im Vergleich dazu hat die Secundus Bank keinen Einfluss auf das Repository, aus dem sie das Bild bezieht. Daher kann sie diese Annahme nicht sicher treffen. Stattdessen autorisieren sie den Zugriff auf die Arbeitslast basierend auf ihrem image_digest. Im Gegensatz zu image_reference, das Primus Bank so ändern könnte, dass es auf ein anderes Bild verweist, kann Primus Bank image_digest nicht auf ein anderes Bild verweisen lassen als das, das Secundus Bank im vorherigen Schritt geprüft hat.

Bevor Sie Workload Identity-Poolanbieter erstellen, erfassen Sie die image_digest für das Workload-Container-Image, die in den Attributbedingungen des Anbieters verwendet wird.

export WORKLOAD_IMAGE_DIGEST=$(gcloud artifacts docker images describe ${PRIMUS_PROJECT_REPOSITORY_REGION}-docker.pkg.dev/$PRIMUS_PROJECT_ID/$PRIMUS_ARTIFACT_REPOSITORY/$WORKLOAD_IMAGE_NAME:$WORKLOAD_IMAGE_TAG  --format="value(image_summary.digest)" --project ${PRIMUS_PROJECT_ID})

gcloud config set project $SECUNDUS_PROJECT_ID

gcloud iam workload-identity-pools providers create-oidc $SECUNDUS_WIP_PROVIDER \
  --location="global" \
  --workload-identity-pool="$SECUNDUS_WORKLOAD_IDENTITY_POOL" \
  --issuer-uri="https://confidentialcomputing.googleapis.com/" \
  --allowed-audiences="https://sts.googleapis.com" \
  --attribute-mapping="google.subject='assertion.sub'" \
  --attribute-condition="assertion.swname == 'CONFIDENTIAL_SPACE' && 
'STABLE' in assertion.submods.confidential_space.support_attributes && 
assertion.submods.container.image_digest == '${WORKLOAD_IMAGE_DIGEST}' &&
 assertion.submods.container.image_reference == '${PRIMUS_PROJECT_REPOSITORY_REGION}-docker.pkg.dev/$PRIMUS_PROJECT_ID/$PRIMUS_ARTIFACT_REPOSITORY/$WORKLOAD_IMAGE_NAME:$WORKLOAD_IMAGE_TAG' && 
'$WORKLOAD_SERVICE_ACCOUNT@$SECUNDUS_PROJECT_ID.iam.gserviceaccount.com' in assertion.google_service_accounts"

Arbeitslast(en) ausführen

In diesem Schritt führt die Secundus Bank die Arbeitslast in Confidential Space aus. Diese Arbeitslast erhält die Zugriffstokens aus dem Workload Identity-Pool von Primus und dem Workload Identity-Pool von Secundus, um die Kundendaten der Primus-Bank bzw. der Secundus-Bank zu lesen und zu entschlüsseln.

Erforderliche TEE-Argumente werden mit dem Metadaten-Flag übergeben. Argumente für den Arbeitslastcontainer werden über den Teil „tee-cmd“ des Flags übergeben. Das Ergebnis der Workload-Ausführung wird in $SECUNDUS_RESULT_STORAGE_BUCKET veröffentlicht.

Erste Arbeitslast ausführen

Bei der ersten Ausführung der Arbeitslast werden die Kunden der Primus Bank anhand des angegebenen Standorts in den Arbeitslastcontainerargumenten gezählt. Wie unten dargestellt, führt die erste Arbeitslast den Befehl „count-location“ aus und das Ergebnis wird unter $SECUNDUS_RESULT_STORAGE_BUCKET/seattle-result gespeichert.

gcloud compute instances create ${WORKLOAD_VM1} \
 --project=${SECUNDUS_PROJECT_ID} \
 --confidential-compute-type=SEV \
 --shielded-secure-boot \
 --maintenance-policy=MIGRATE \
 --scopes=cloud-platform \
 --zone=${SECUNDUS_PROJECT_ZONE} \
 --image-project=confidential-space-images \
 --image-family=confidential-space \
--service-account=${WORKLOAD_SERVICE_ACCOUNT}@${SECUNDUS_PROJECT_ID}.iam.gserviceaccount.com \
 --metadata "^~^tee-image-reference=${PRIMUS_PROJECT_REPOSITORY_REGION}-docker.pkg.dev/${PRIMUS_PROJECT_ID}/${PRIMUS_ARTIFACT_REPOSITORY}/${WORKLOAD_IMAGE_NAME}:${WORKLOAD_IMAGE_TAG}~tee-restart-policy=Never~tee-cmd="[\"count-location\",\"Seattle\",\"gs://${SECUNDUS_RESULT_STORAGE_BUCKET}/seattle-result\"]""

Ergebnisse ansehen

Sehen Sie sich im Secundus-Projekt die Ergebnisse der ersten Arbeitslast an. Warten Sie 3 bis 5 Minuten, bis die Ausführung der Arbeitslast abgeschlossen ist und das Ergebnis im Cloud-Speicher-Bucket verfügbar ist.

gcloud config set project $SECUNDUS_PROJECT_ID

gsutil cat gs://$SECUNDUS_RESULT_STORAGE_BUCKET/seattle-result

Das Ergebnis sollte 3 sein, da dies die Anzahl der Personen aus Seattle ist, die in der Datei primus_customer_list.csv aufgeführt sind.

Hinweis:Sie können zwei Image-Familien für die Instanz verwenden: confidential-space-debug und confidential-space. Sie können eine davon verwenden. Der Hauptunterschied besteht darin, dass bei confidential-space Dienste deaktiviert sind, die es dem Betreiber nicht ermöglichen, die Arbeitslast zu beeinflussen. Bei confidential-space-debug ist dagegen SSH aktiviert und der Betreiber kann über SSH eine Verbindung zur VM herstellen. So kann der Betreiber Fehler beheben. Der Attestation-Dienst notiert jedoch im Attestation-Token, dass der Debug-Status aktiviert ist. Sie müssen die VM danach jedoch manuell herunterfahren.

Zweite Arbeitslast ausführen

Bei der Ausführung der zweiten Arbeitslast ermitteln wir die gemeinsamen Kunden der Primus- und der Secundus-Bank. Wie unten dargestellt, führt die zweite Arbeitslast den Befehl „list-common-customers“ aus und das Ergebnis wird unter $SECUNDUS_RESULT_STORAGE_BUCKET/list-common-count gespeichert.

gcloud compute instances create ${WORKLOAD_VM2} \
 --project=${SECUNDUS_PROJECT_ID} \
 --confidential-compute-type=SEV \
 --shielded-secure-boot \
 --maintenance-policy=MIGRATE \
 --scopes=cloud-platform \
 --zone=${SECUNDUS_PROJECT_ZONE} \
 --image-project=confidential-space-images \
 --image-family=confidential-space \
--service-account=${WORKLOAD_SERVICE_ACCOUNT}@${SECUNDUS_PROJECT_ID}.iam.gserviceaccount.com \
  --metadata "^~^tee-image-reference=${PRIMUS_PROJECT_REPOSITORY_REGION}-docker.pkg.dev/${PRIMUS_PROJECT_ID}/${PRIMUS_ARTIFACT_REPOSITORY}/${WORKLOAD_IMAGE_NAME}:${WORKLOAD_IMAGE_TAG}~tee-restart-policy=Never~tee-cmd="[\"list-common-customers\",\"gs://$SECUNDUS_RESULT_STORAGE_BUCKET/list-common-result\"]""

Ergebnisse ansehen

Sehen Sie sich im Projekt „Secundus“ die Ergebnisse der zweiten Arbeitslast an. Warten Sie 3 bis 5 Minuten, bis die Ausführung der Arbeitslast abgeschlossen ist und das Ergebnis im Cloud-Speicher-Bucket verfügbar ist.

gcloud config set project $SECUNDUS_PROJECT_ID

gsutil cat gs://$SECUNDUS_RESULT_STORAGE_BUCKET/list-common-result

Das Ergebnis sollte die folgende Liste sein, da dies die gemeinsamen Kunden der Primus- und Secundus-Bank sind.

Ausgabe:

Eric
Clinton
Ashley
Cooper

Nicht autorisierte Arbeitslast ausführen

Der Vertrag der Primus-Bank, der der Secundus-Bank Zugriff auf ihre Daten gewährt, läuft ab. Die Primus Bank aktualisiert daher ihre Attributbedingung, um VMs mit dem Dienstkonto ihres neuen Partners, der Tertius Bank, zuzulassen.

Primus Bank ändert den Workload Identity Pool-Anbieter

Aktualisieren Sie in $PRIMUS_PROJECT_ID die Attributbedingung für den Identitätsanbieter des Attestation Verifier, um Arbeitslasten an einem neuen Speicherort zu autorisieren.

1. Legen Sie das Projekt auf $PRIMUS_PROJECT_ID fest.

gcloud config set project $PRIMUS_PROJECT_ID

2. Exportieren Sie die GCP-Projekt-ID der Tertius Bank mit dem folgenden Befehl. Später verwendet die Primus Bank diese Informationen, um die Attributbedingung des Workload Identity-Poolanbieters zu aktualisieren. Die Primus-Bank wird die Autorisierung der Arbeitslastdienstkonten der Secundus-Bank nicht beenden. Jetzt sind Dienstkonten für die Arbeitslast der Tertius Bank zulässig.

export TERTIUS_PROJECT_ID=<GCP project-id of Tertius Bank>

3. Aktualisieren Sie den OIDC-Anbieter im Workload Identity-Pool. Hier wird '$WORKLOAD_SERVICE_ACCOUNT@$SECUNDUS_PROJECT_ID.iam.gserviceaccount.com' in assertion.google_service_accounts in '$WORKLOAD_SERVICE_ACCOUNT@$TERTIUS_PROJECT_ID.iam.gserviceaccount.com' in assertion.google_service_accounts. geändert. Anstatt das Arbeitslastdienstkonto der Secundus-Bank zu autorisieren, wird jetzt das Arbeitslastdienstkonto der Tertius-Bank autorisiert.

gcloud iam workload-identity-pools providers update-oidc $PRIMUS_WIP_PROVIDER \
  --location="global" \
  --workload-identity-pool="$PRIMUS_WORKLOAD_IDENTITY_POOL" \
  --issuer-uri="https://confidentialcomputing.googleapis.com/" \
  --allowed-audiences="https://sts.googleapis.com" \
  --attribute-mapping="google.subject='assertion.sub'" \
  --attribute-condition="assertion.swname == 'CONFIDENTIAL_SPACE' && 
   'STABLE' in assertion.submods.confidential_space.support_attributes &&
   assertion.submods.container.image_reference == '${PRIMUS_PROJECT_REPOSITORY_REGION}-docker.pkg.dev/$PRIMUS_PROJECT_ID/$PRIMUS_ARTIFACT_REPOSITORY/$WORKLOAD_IMAGE_NAME:$WORKLOAD_IMAGE_TAG' && 
'$WORKLOAD_SERVICE_ACCOUNT@$TERTIUS_PROJECT_ID.iam.gserviceaccount.com' in assertion.google_service_accounts"

Arbeitslast noch einmal ausführen

Wenn die Secundus Bank versucht, die ursprüngliche Arbeitslast auszuführen, schlägt dies fehl. Wenn Sie den Fehler sehen möchten, löschen Sie die ursprüngliche Ergebnisdatei und die VM-Instanz und versuchen Sie dann noch einmal, die Arbeitslast auszuführen.

Vorhandene Ergebnisdatei und VM-Instanz löschen

1. Legen Sie das Projekt auf $SECUNDUS_PROJECT_ID fest.

gcloud config set project $SECUNDUS_PROJECT_ID

2. Löschen Sie die Ergebnisdatei.

gsutil rm gs://$SECUNDUS_RESULT_STORAGE_BUCKET/list-common-result

3. Löschen Sie die Confidential VM-Instanz.

gcloud compute instances delete ${WORKLOAD_VM2} --zone=${SECUNDUS_PROJECT_ZONE}

Führen Sie die nicht autorisierte Arbeitslast aus:

gcloud compute instances create ${WORKLOAD_VM2} \
 --confidential-compute-type=SEV \
 --shielded-secure-boot \
 --maintenance-policy=MIGRATE \
 --scopes=cloud-platform \
 --zone=${SECUNDUS_PROJECT_ZONE}\
 --image-project=confidential-space-images \
 --image-family=confidential-space \
--service-account=${WORKLOAD_SERVICE_ACCOUNT}@${SECUNDUS_PROJECT_ID}.iam.gserviceaccount.com \
 --metadata "^~^tee-image-reference=${PRIMUS_PROJECT_REPOSITORY_REGION}-docker.pkg.dev/${PRIMUS_PROJECT_ID}/${PRIMUS_ARTIFACT_REPOSITORY}/${WORKLOAD_IMAGE_NAME}:${WORKLOAD_IMAGE_TAG}~tee-restart-policy=Never~tee-cmd="[\"list-common-customers\",\"gs://$SECUNDUS_RESULT_STORAGE_BUCKET/list-common-result\"]""

Hinweis:Sie können zwei Image-Familien für die Instanz verwenden: confidential-space-debug und confidential-space. Sie können eine davon verwenden. Der Hauptunterschied besteht darin, dass bei confidential-space Dienste deaktiviert sind, die es dem Betreiber nicht ermöglichen, die Arbeitslast zu beeinflussen. Bei confidential-space-debug ist dagegen SSH aktiviert und der Betreiber kann über SSH eine Verbindung zur VM herstellen. So kann der Betreiber Fehler beheben. Der Attestation-Dienst notiert jedoch im Attestation-Token, dass der Debug-Status aktiviert ist. Sie müssen die VM danach jedoch manuell herunterfahren.

Fehler ansehen

Anstelle der Ergebnisse der Arbeitslast wird ein Fehler (The given credential is rejected by the attribute condition) angezeigt.

gsutil cat gs://$SECUNDUS_RESULT_STORAGE_BUCKET/list-common-result

Ähnlich verhält es sich, wenn die Primus Bank die Arbeitslast heimlich so ändert, dass die gesamte Kundenliste der Secundus Bank an einen Bucket gesendet wird, der der Primus Bank gehört. Dieser Versuch würde fehlschlagen, da sich der Digest der schädlichen Arbeitslast vom Image-Digest unterscheidet, der im Workload Identity-Pool der Secundus Bank autorisiert wurde.

5. Bereinigen

Hier finden Sie das Script, mit dem Sie die im Rahmen dieses Codelabs erstellten Ressourcen bereinigen können. Im Rahmen dieser Bereinigung werden die folgenden Ressourcen gelöscht:

• Cloud Storage-Eingabe-Bucket der Primus Bank ($PRIMUS_INPUT_STORAGE_BUCKET).
• Ein Dienstkonto der Primus Bank ($PRIMUS_SERVICE_ACCOUNT).
• Eine Artifact Registry der Primus Bank, die Bildsignaturen enthält ($PRIMUS_COSIGN_REPOSITORY).
• Ein Workload Identity-Pool der Primus Bank($PRIMUS_WORKLOAD_IDENTITY_POOL).
• Ein Arbeitslastdienstkonto der Secundus Bank ($WORKLOAD_SERVICE_ACCOUNT).
• Cloud Storage-Eingabe-Bucket der Secundus Bank ($SECUNDUS_INPUT_STORAGE_BUCKET).
• Ein Dienstkonto der Secundus Bank ($SECUNDUS_SERVICE_ACCOUNT).
• Eine Artifact Registry der Secundus Bank, die Bildsignaturen enthält ($SECUNDUS_COSIGN_REPOSITORY).
• Ein Workload Identity-Pool der Secundus Bank($SECUNDUS_WORKLOAD_IDENTITY_POOL).
• Ein Arbeitslastdienstkonto der Secundus Bank ($WORKLOAD_SERVICE_ACCOUNT).
• Workload Compute-Instanzen
• Der Ergebnis-Storage-Bucket der Secundus Bank ($SECUNDUS_RESULT_STORAGE_BUCKET).
• Ein Artifact-Repository der Primus Bank ($PRIMUS_ARTIFACT_REPOSITORY).

./cleanup.sh

Wenn Sie mit der explorativen Datenanalyse fertig sind, sollten Sie Ihr Projekt löschen.

• Rufen Sie die Cloud Platform Console auf.
• Wählen Sie das Projekt aus, das Sie beenden möchten, und klicken Sie oben auf „Löschen“. Das Projekt wird dann zum Löschen geplant.

Glückwunsch

Herzlichen Glückwunsch, Sie haben das Codelab erfolgreich abgeschlossen.

Sie haben gelernt, wie Sie mit Confidential Space freigegebene Daten schützen und gleichzeitig ihre Vertraulichkeit wahren.

Was liegt als Nächstes an?

Sehen Sie sich diese ähnlichen Codelabs an:

• Codelab zu signierten Container-Images
• So werden digitale Assets mit Multi-Party Computation und Confidential Space bearbeitet
• Vertrauliche Daten mit Confidential Spaces analysieren

Weitere Informationen

• Fühlst du dich isoliert? Confidential Computing als Lösung
• Confidential Computing in der GCP
• Confidential Space: Die Zukunft der datenschutzfreundlichen Zusammenarbeit
• So sorgen Google und Intel für mehr Sicherheit bei Confidential Computing
• Datenschutz und Fortschritt – Sicherheit mit Google Cloud Confidential Computing verbessern