Mit Confidential Space geschützte freigegebene Daten schützen

1. Übersicht

Confidential Space bietet sicheren Datenaustausch und Zusammenarbeit zwischen 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.

Confidential Space ermöglicht Szenarien, in denen Sie durch das Aggregieren und Analysieren sensibler, oft regulierter Daten einen gegenseitigen Mehrwert erzielen und gleichzeitig die volle Kontrolle darüber behalten. Mit Confidential Space können Organisationen durch das Aggregieren und Analysieren sensibler Daten wie personenidentifizierbarer Informationen (PII), geschützter Gesundheitsdaten (PHI), geistigen Eigentums und kryptografischer Secrets einen gegenseitigen Mehrwert erzielen und gleichzeitig die volle Kontrolle darüber behalten.

Voraussetzungen

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

Lerninhalte

• Erforderliche Cloud-Ressourcen für die Ausführung von Confidential Space konfigurieren
• Arbeitslast in einer Confidential VM ausführen, auf der das Confidential Space-VM-Image ausgeführt wird
• So autorisieren Sie den Zugriff auf geschützte Ressourcen basierend auf den Attributen des Arbeitslastcodes (was), der Confidential Space-Umgebung (wo) und des Kontos, mit dem die Arbeitslast ausgeführt wird (wer).

In diesem Codelab richten Sie einen vertraulichen Bereich zwischen Primus und 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. Primus Bank und Secundus Bank speichern ihre Kundendaten in Cloud Storage-Buckets und verschlüsseln die Daten mit Cloud Key Management Service-Schlüsseln.
• Schritt 2: Dienstkonto für die Arbeitslast erstellen, das von der VM für die Arbeitslast verwendet wird. Die Secundus Bank, die die Arbeitslast betreibt, startet die Arbeitslast-VM. Die Primus Bank würde den Arbeitslastcode erstellen.
• Schritt 3: Erstellen Sie einen Arbeitslast, der zwei CLI-Befehle enthält: einen zum Zählen der Kunden am angegebenen Standort und einen zum Ermitteln der gemeinsamen Kunden von 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 Primus Bank würde einen Workload Identity-Pool verwenden, um Arbeitslasten den Zugriff auf Kundendaten zu autorisieren. Die Autorisierung würde auf Attributen basieren, die Aufschluss darüber geben, wer die Arbeitslast ausführt, was die Arbeitslast tut und wo sie ausgeführt wird.
• Schritt 5: Wenn die Arbeitslast ausgeführt wird, wird Zugriff auf die Cloud-Ressourcen der Datenpartner (Primus Bank und Secundus Bank) angefordert, indem ein Attestation Verifier-Dienst-Token mit Arbeitslast- und Umgebungsansprüchen angeboten wird. Wenn die Arbeitslastmessungsansprüche im Token mit der Attributbedingung in den Workload Identity-Pools von Primus und Secundus Bank übereinstimmen, wird das Dienstkonto-Zugriffstoken zurückgegeben, das die Berechtigung für den Zugriff auf die entsprechenden Cloud-Ressourcen hat. Auf die Cloud-Ressourcen kann nur über die Arbeitslast zugegriffen werden, die in Confidential Space ausgeführt wird.
• Schritt 5a: Führen Sie die erste Arbeitslast aus, mit der Primus Bank-Kunden aus bestimmten Standorten gezählt werden. Für diese Arbeitslast wäre Primus Bank ein Datenbearbeiter und Arbeitslastautor, der die verschlüsselte Kundenliste für die Arbeitslast bereitstellt, die in Confidential Space ausgeführt wird. Die Secundus Bank wäre ein Arbeitslastoperator und würde die Arbeitslast in einem Confidential Space ausführen.
• Schritt 5b: Führen Sie den zweiten Arbeitslast aus, um die gemeinsamen Kunden von Primus und Secundus Banks zu ermitteln. Für diesen Arbeitslasttyp wären Primus Bank und Secundus Bank beide Datenpartner. Sie würden die verschlüsselten Kundenlisten für die Arbeitslast bereitstellen, die in Confidential Space ausgeführt wird. Secundus Bank wäre wieder ein Workload-Operator. Diese Arbeitslast würde auch von der Secundus Bank autorisiert, da sie für die Suche nach gemeinsamen Kunden auch auf die verschlüsselten Kundenlisten der Secundus Bank zugreifen muss. In diesem Fall würde Secundus Bank der Arbeitslast den Zugriff auf ihre Kundendaten auf Grundlage der Attribute des Nutzers, der die Arbeitslast ausführt, der Funktion der Arbeitslast und des Ortes, an dem die Arbeitslast ausgeführt wird, autorisieren, wie in Schritt 4 für Primus Bank beschrieben.

2. Cloud-Ressourcen einrichten

Hinweis

• Klonen Sie dieses Repository mit dem folgenden Befehl, um die erforderlichen Skripts 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 Umgebungsvariablen für das Projekt wie unten gezeigt festgelegt haben. Weitere Informationen zum Erstellen eines GCP-Projekts finden Sie in diesem Codelab. Hier finden Sie 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 die Variablen für Ressourcennamen mit diesem Befehl wie unten beschrieben fest. Sie können die Ressourcennamen mit diesen Variablen überschreiben, z. B. export PRIMUS_INPUT_STORAGE_BUCKET='my-input-bucket'.
• Sie können die folgenden Variablen mit vorhandenen Cloud-Ressourcennamen 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 die neue Cloud-Ressource wird im Rahmen des Folgenden 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 Anbieter des Workload Identity-Pools von Primus Bank, der die Autorisierungsbedingung für die Verwendung von Tokens enthält, 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 sie die Berechtigung, die im Bucket $PRIMUS_INPUT_STORAGE_BUCKET gespeicherten Kundendaten anzusehen.
$PRIMUS_ENC_KEY	Der KMS-Schlüssel, der zum Verschlüsseln der in $PRIMUS_INPUT_STORAGE_BUCKET gespeicherten Daten für Primus Bank verwendet wird.
$PRIMUS_ENC_KEYRING	Der KMS-Schlüsselbund, der zum Erstellen des Verschlüsselungsschlüssels $PRIMUS_ENC_KEY für Primus Bank verwendet wird.
$PRIMUS_ARTIFACT_REPOSITORY	Das Artefakt-Repository, in das das Docker-Image für die Arbeitslast übertragen wird.

• Sie können die folgenden Variablen mit vorhandenen Cloud-Ressourcennamen 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 die neue Cloud-Ressource wird im Rahmen des Folgenden 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 Anbieter des Workload Identity-Pools von Secundus Bank, der die Autorisierungsbedingung für die Verwendung von Tokens enthält, die vom Attestation Verifier Service signiert wurden.
$SECUNDUS_SERVICE_ACCOUNT	Das Dienstkonto der Secundus Bank, das von $SECUNDUS_WORKLOAD_IDENTITY_POOL für den Zugriff auf die geschützten Ressourcen verwendet wird. In diesem Schritt hat sie die Berechtigung, die im Bucket $SECUNDUS_INPUT_STORAGE_BUCKET gespeicherten Kundendaten anzusehen.
$SECUNDUS_ENC_KEY	Der KMS-Schlüssel, der zum Verschlüsseln der in $SECUNDUS_INPUT_STORAGE_BUCKET für die Secundus Bank gespeicherten Daten verwendet wird.
$SECUNDUS_ENC_KEYRING	Der KMS-Schlüsselbund, der zum Erstellen des Verschlüsselungsschlüssels $SECUNDUS_ENV_KEY für Secundus Bank verwendet wird.
$SECUNDUS_RESULT_STORAGE_BUCKET	Der Bucket, in dem die Arbeitslastergebnisse gespeichert werden.
$WORKLOAD_IMAGE_NAME	Der Name des Container-Images der Arbeitslast.
$WORKLOAD_IMAGE_TAG	Das Tag des Arbeitslast-Container-Images.
$WORKLOAD_SERVICE_ACCOUNT	Das Dienstkonto, das die Berechtigung hat, auf die Confidential VM zuzugreifen, auf der die Arbeitslast ausgeführt wird.

• In diesem Codelab werden nur wenige Artefakte verwendet, wie unten beschrieben:
• primus_customer_list.csv: Die Datei, die die Kundendaten der Primus Bank enthält. Hier finden Sie die in diesem Codelab verwendete Beispieldatei.
• secundus_customer_list.csv: Die Datei, die die Kundendaten der Secundus Bank enthält. Hier finden Sie die in diesem Codelab verwendete Beispieldatei.
• Sie benötigen bestimmte Berechtigungen für diese beiden Projekte:
• Für $PRIMUS_PROJECT_ID benötigen Sie die Rollen „Cloud KMS-Administrator“, „Storage-Administrator“, „Artifact Registry-Administrator“, „Dienstkonto-Administrator“ und „IAM Workload Identity-Pooladministrator“.
• Für die $SECUNDUS_PROJECT_ID benötigen Sie die Rollen „Compute-Administrator“, „Storage-Administrator“, „Dienstkontoadministrator“, „Cloud KMS-Administrator“, „IAM Workload Identity-Pooladministrator“ und optional „Sicherheitsadministrator“.
• Führen Sie das folgende Skript 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 Skript aus, um die Ressourcen für 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) zum Validieren von Ansprüchen basierend auf Attributbedingungen, die unter dem zugehörigen Anbieter konfiguriert sind.
• Das Dienstkonto ($PRIMUS_SERVICE_ACCOUNT), das dem oben genannten Workload Identity-Pool ($PRIMUS_WORKLOAD_IDENTITY_POOL) zugeordnet ist, hat Zugriff auf das Entschlüsseln von Daten mit dem KMS-Schlüssel (mit der Rolle roles/cloudkms.cryptoKeyDecrypter), das Lesen von Daten aus dem Cloud Storage-Bucket (mit der Rolle objectViewer) und das Verbinden des Dienstkontos mit dem Workload Identity-Pool (mit roles/iam.workloadIdentityUser).

./setup_primus_bank_resources.sh

Cloud-Ressourcen für Secundus Bank einrichten

Für die Secundus Bank sind die folgenden Cloud-Ressourcen erforderlich. Führen Sie dieses Skript aus, um die Ressourcen der Secundus Bank einzurichten. Im Rahmen dieser Schritte werden die unten genannten 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) zum Validieren von Ansprüchen basierend auf Attributbedingungen, die unter dem zugehörigen Anbieter konfiguriert sind.
• Das Dienstkonto ($SECUNDUS_SERVICE_ACCOUNT), das dem oben genannten Workload Identity-Pool ($SECUNDUS_WORKLOAD_IDENTITY_POOL) zugeordnet ist, hat Zugriff auf das Entschlüsseln von Daten mit dem KMS-Schlüssel (mit der Rolle roles/cloudkms.cryptoKeyDecrypter), das Lesen von Daten aus dem Cloud Storage-Bucket (mit der Rolle objectViewer) und das Verbinden des Dienstkontos mit dem Workload Identity-Pool (mit der Rolle roles/iam.workloadIdentityUser).
• Cloud Storage-Bucket ($SECUNDUS_RESULT_STORAGE_BUCKET) zum Speichern des Ergebnisses der Arbeitslastausführung durch Secundus Bank.

./setup_secundus_bank_resources.sh

3. Arbeitslast erstellen

Dienstkonto für Arbeitslast erstellen

Als Nächstes erstellen Sie ein Dienstkonto für den Arbeitslast mit den erforderlichen Rollen und Berechtigungen, wie unten beschrieben. Führen Sie das folgende Script aus, um ein Dienstkonto für Arbeitslasten im Secundus Bank-Projekt zu erstellen. Die VM, auf der der Arbeitslast ausgeführt wird, würde dieses Dienstkonto verwenden.

Dieses Dienstkonto für Arbeitslasten ($WORKLOAD_SERVICE_ACCOUNT) hat die folgenden Rollen:

• Weisen Sie dem Dienstkonto der Arbeitslast die Rolle confidentialcomputing.workloadUser zu . Dadurch kann mit dem Nutzerkonto ein Attestierungstoken generiert werden.
• Weisen Sie dem Dienstkonto der Arbeitslast die Rolle logging.logWriter zu. Dadurch kann die Confidential Space-Umgebung zusätzlich zur seriellen Konsole Logs in Cloud Logging schreiben, 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 Arbeitslast, die in diesem Codelab verwendet wird. Die Arbeitslast ist eine einfache GoLang-Anwendung, die Folgendes ausführt:

• Zählt Kunden an einem bestimmten geografischen Standort.
• Sucht in den Kundenlisten, die in den jeweiligen Cloud Storage-Buckets gespeichert sind, nach gemeinsamen Kunden von Primus und Secundus Bank.

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

• Erstellen Sie eine Artifact Registry ($PRIMUS_ARTIFACT_REPOSITORY), die Primus Bank gehört und in der die Arbeitslast veröffentlicht wird.
• Generieren Sie den Code und aktualisieren Sie ihn mit den erforderlichen Ressourcennamen. Der in diesem Codelab verwendete Arbeitslastcode ist hier verfügbar.
• Code erstellen und in einem Docker-Image verpacken Das entsprechende Dockerfile finden Sie hier.
• Veröffentlichen Sie das Docker-Image in der Artifact Registry ($PRIMUS_ARTIFACT_REGISTRY) von Primus Bank.
• Gewähren Sie dem Dienstkonto $WORKLOAD_SERVICE_ACCOUNT die Leseberechtigung für Artifact Registry ($PRIMUS_ARTIFACT_REGISTRY).

./create_workload.sh

4. Arbeitslast(en) autorisieren und ausführen

Arbeitslast autorisieren

Die Primus Bank möchte Arbeitslasten autorisieren, auf ihre Kundendaten zuzugreifen. Die Autorisierung soll auf Attributen der folgenden Ressourcen basieren:

• Was: Code, der überprüft wird
• Wo: Eine sichere Umgebung
• Wer: Ein vertrauenswürdiger Betreiber

Primus verwendet die Workload Identity-Föderation, um eine Zugriffsrichtlinie basierend auf diesen Anforderungen zu erzwingen.

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

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

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

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 für die Primus Bank erstellten WIP möchte die Secundus Bank Arbeitslasten autorisieren, auf ihre Kundendaten zuzugreifen. Die Autorisierung soll auf folgenden Kriterien basieren:

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

Die Primus Bank verwendet den image_reference-Anspruch, der das Bild-Tag enthält, um zu entscheiden, ob sie den Zugriff autorisieren soll. Sie haben die Kontrolle über das Remote-Repository und können daher sicher sein, dass nur Bilder getaggt werden, bei denen keine Daten preisgegeben werden.

Im Vergleich dazu hat die Secundus Bank keine Kontrolle über das Repository, aus dem sie das Bild bezieht, sodass sie diese Annahme nicht sicher treffen kann. Stattdessen autorisieren sie den Zugriff auf die Arbeitslast basierend auf ihrem image_digest. Im Gegensatz zum image_reference, das Primus Bank ändern könnte, um auf ein anderes Bild zu verweisen, könnte Primus Bank nicht dafür sorgen, dass sich das image_digest auf ein anderes Bild bezieht als das, das Secundus Bank im vorherigen Schritt geprüft hat.

Bevor Workload Identity-Poolanbieter erstellt werden, erfassen wir die image_digest für das Workload-Container-Image, die in den Attributbedingungen des Anbieters verwendet werden.

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

Im Rahmen dieses Schritts führt Secundus Bank die Arbeitslast in Confidential Space aus. Für diese Arbeitslast werden die Zugriffstokens aus dem Workload Identity-Pool von Primus und dem Workload Identity-Pool von Secundus abgerufen, um die Kundendaten der Primus Bank bzw. der Secundus Bank zu lesen und zu entschlüsseln.

Erforderliche TEE-Argumente werden über das 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

Im Rahmen der ersten Ausführung der Arbeitslast werden die Kunden der Primus Bank vom angegebenen Standort in den Argumenten des Arbeitslastcontainers gezählt. Wie unten dargestellt, wird im ersten Arbeitslast der Befehl „count-location“ ausgeführt und das Ergebnis 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 Storage-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 in confidential-space Dienste deaktiviert sind, sodass der Bediener nicht in die Arbeitslast eingreifen kann. In confidential-space-debug ist SSH aktiviert und der Bediener kann eine SSH-Verbindung zur VM herstellen. So kann der Betreiber Fehler beheben. Der Attestierungsdienst vermerkt jedoch im Attestierungstoken, dass der Debugging-Status aktiviert ist. Sie müssen die VM jedoch anschließend manuell herunterfahren.

Zweite Arbeitslast ausführen

Im Rahmen der zweiten Ausführung des Arbeitslastprozesses ermitteln wir die gemeinsamen Kunden der Primus Bank und der Secundus Bank. Wie unten dargestellt, wird beim zweiten Arbeitslast der Befehl „list-common-customers“ ausgeführt 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 Storage-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 von Primus und Secundus Bank sind.

Ausgabe:

Eric
Clinton
Ashley
Cooper

Nicht autorisierte Arbeitslast ausführen

Der Vertrag der Primus Bank, der der Secundus Bank den Zugriff auf ihre Daten ermöglicht, läuft ab. Primus Bank aktualisiert daher die Attributbedingung, um VMs mit dem Dienstkonto des neuen Partners, Tertius Bank, zuzulassen.

Primus Bank ändert den Workload Identity-Poolanbieter

Aktualisieren Sie im $PRIMUS_PROJECT_ID die Attributbedingung für den Attestation Verifier-Identitätsanbieter, um Workloads an einem neuen Standort zu autorisieren.

1. Setzen Sie das Projekt auf $PRIMUS_PROJECT_ID.

gcloud config set project $PRIMUS_PROJECT_ID

2. Exportieren Sie die GCP-Projekt-ID der Tertius Bank mit dem folgenden Befehl. Später würde die Primus Bank dies verwenden, um die Attributbedingung des Workload Identity-Poolanbieters zu aktualisieren. Primus Bank wird die Autorisierung der Arbeitslast-Dienstkonten der Secundus Bank nicht beenden. Jetzt sind Dienstkonten für Tertius Bank-Arbeitslasten 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 Arbeitslast-Dienstkonto von Secundus Bank zu autorisieren, wird jetzt das Arbeitslast-Dienstkonto von 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 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 das $SECUNDUS_PROJECT_ID-Projekt 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 in confidential-space Dienste deaktiviert sind, sodass der Bediener nicht in die Arbeitslast eingreifen kann. In confidential-space-debug ist SSH aktiviert und der Bediener kann eine SSH-Verbindung zur VM herstellen. So kann der Betreiber Fehler beheben. Der Attestierungsdienst vermerkt jedoch im Attestierungstoken, dass der Debugging-Status aktiviert ist. Sie müssen die VM jedoch anschließend 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

Wenn Primus Bank die Arbeitslast heimlich ändert, um die gesamte Kundenliste der Secundus Bank an einen Bucket zu senden, der Primus Bank gehört, würde dieser Versuch fehlschlagen, da der Digest der schädlichen Arbeitslast sich vom Image-Digest unterscheidet, der im Workload Identity-Pool der Secundus Bank autorisiert wurde.

5. Bereinigen

Hier finden Sie das Skript, mit dem die Ressourcen bereinigt werden können, die wir im Rahmen dieses Codelabs erstellt haben. 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 ($PRIMUS_COSIGN_REPOSITORY) enthält.
• Ein Workload Identity-Pool der Primus Bank($PRIMUS_WORKLOAD_IDENTITY_POOL).
• Ein Arbeitslast-Dienstkonto 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, in der Bildsignaturen ($SECUNDUS_COSIGN_REPOSITORY) gespeichert werden.
• Ein Workload Identity-Pool der Secundus Bank($SECUNDUS_WORKLOAD_IDENTITY_POOL).
• Ein Arbeitslast-Dienstkonto der Secundus Bank ($WORKLOAD_SERVICE_ACCOUNT).
• Compute-Instanzen für Arbeitslasten.
• Der Ergebnis-Storage-Bucket der Secundus Bank ($SECUNDUS_RESULT_STORAGE_BUCKET).
• Ein Artefakt-Repository der Primus Bank ($PRIMUS_ARTIFACT_REPOSITORY).

./cleanup.sh

Wenn Sie 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

Sie haben das Codelab erfolgreich abgeschlossen.

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

Nächste Schritte

Sehen Sie sich einige dieser ähnlichen Codelabs an:

• Codelab für signierte 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
• Confidential Computing in der GCP
• Confidential Space: Die Zukunft der datenschutzfreundlichen Zusammenarbeit
• Wie Google und Intel Confidential Computing sicherer machen
• Datenschutz und Fortschritt – Sicherheit mit Confidential Computing in Google Cloud verbessern