Informationen zu diesem Codelab
1. Übersicht
Dieses Codelab baut auf dem Codelab zu vertraulichen Gruppenbereichen auf. Unterstützung für signierte Container-Images, mit der sich ein Container mit einem attestierten öffentlichen Schlüssel authentifizieren lässt, anstatt den Image-Digest in der Workload Identity-Pool-Richtlinie anzugeben.
Was sich bei der Unterstützung signierter Container-Images in Confidential Space geändert hat:
Verbesserte Nutzerfreundlichkeit: Mit der Einführung der Funktion für signierte Container-Images können wir jetzt von einem Ansatz mit Arbeitslast-Image-Digest zu einem Ansatz mit Containersignatur für Mitbearbeiter/Auditoren wechseln, die ein Image autorisieren.
- Wenn Sie Image-Digests direkt verwenden, müssen Ressourceninhaber ihre Richtlinien jedes Mal mit einem Image-Digest aktualisieren, wenn sie ein neues Image autorisieren. Bei Verwendung von Bildsignaturen enthält die Richtlinie einen öffentlichen Schlüssel-Fingerabdruck, dessen entsprechender privater Schlüssel dem Mitbearbeiter/Auditor gehört und zum Signieren der geprüften Bilder verwendet wird.
- Bei einigen Sicherheitsmodellen ist es einfacher, auf einen vertrauenswürdigen Signaturschlüssel für Bilder zu verweisen, als eine Liste mit neuen Hash-Werten für Bilder zu aktualisieren.
Keine Sicherheitsregression: Dieser Ansatz für Containersignaturen führt im Vergleich zum vorherigen Ansatz mit Image-Digests zu keiner Sicherheitsregression, da die Vertrauensgrenzen gleich bleiben. Beim Ansatz mit Containersignatur autorisiert der Ressourceninhaber einen Überprüfungsschlüssel, indem er den Fingerabdruck des vertrauenswürdigen öffentlichen Schlüssels in der WIP-Richtlinie angibt. Die Autorisierungsüberprüfung wird vom Attestation Verifier Service und WIP durchgeführt. Der Attestation Verifier Service prüft, ob die Signatur mit der laufenden Arbeitslast verknüpft ist, und die WIP-Richtlinie prüft, ob der vom Dienst angegebene öffentliche Schlüssel gemäß Richtlinie autorisiert ist.
Hohe Sicherheit: Mithilfe von Container-Image-Signaturen kann dem Signaturberechtigten des Images ein gewisses Maß an Vertrauen übertragen werden. Wenn der Ressourceninhaber in der Attestierungsrichtlinie den Fingerabdruck des öffentlichen Schlüssels eines vertrauenswürdigen Unterzeichners angibt, autorisiert er diesen Unterzeichner, Bestätigungen dafür abzugeben, welche Container-Images einer Richtlinie entsprechen. Der Attestation Verifier Service prüft, ob die Signatur mit der laufenden Arbeitslast verknüpft ist, und die Richtlinie prüft, ob der öffentliche Schlüssel, mit dem die Signatur erstellt wurde, gemäß Richtlinie autorisiert ist. Durch die zusätzliche Indirektheit, die die Bildsignatur bietet, werden die strengen Sicherheitsgarantien von Confidential Space aufrechterhalten.
Der einzige Unterschied zwischen diesen Ansätzen besteht darin, dass beim letzteren Ansatz eine zusätzliche Indirektheitsebene verwendet wird, bei der Arbeitslast-Images mit einem Signaturschlüssel autorisiert werden. Dadurch entstehen keine neuen Sicherheitslücken, da die Vertrauensgrenzen gleich bleiben.
Aufgaben in diesem Lab
In diesem Codelab erfahren Sie, wie Sie mit einer Container-Image-Signatur den Zugriff auf geschützte Ressourcen autorisieren:
- Geprüftes Container-Image mit
cosign
signieren - Container-Image-Signaturen in OCI-Registre hochladen, um Signaturen zu finden und zu speichern
- Erforderliche Cloud-Ressourcen für den Betrieb von vertraulichen Gruppenbereichen konfigurieren
- Arbeitslast in einem Confidential Space mit Unterstützung für signierte Container-Images ausführen
In diesem Codelab erfahren Sie, wie Sie mit Confidential Space per Remote Attestation ein Container-Image attestieren, das mit einem vertrauenswürdigen Schlüssel signiert wurde und in der Google Compute Engine ausgeführt wird.
Voraussetzungen
- Codelab zu Confidential Space absolvieren
- Google Cloud Platform-Projekt
- Ein Browser, z. B. Chrome oder Firefox
- Erfahrung mit standardmäßigen Linux-Texteditoren wie vim, emacs oder nano
- Grundkenntnisse in Sigstore-Cosignatur
- 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
- Grundkenntnisse zu Artifact Registry
- Grundlegende Kenntnisse zu digitalen Signaturen
Rollen in einem Confidential Space mit signiertem Container-Image
In diesem Codelab ist Primus Bank der Prüfer und Ressourceninhaber, der für Folgendes verantwortlich ist:
- Erforderliche Ressourcen mit Beispieldaten einrichten
- Prüfen des Arbeitslastcodes
- Verwenden von
cosign
zum Signieren des Arbeitslast-Images - Signatur in ein Repository hochladen
- WIP-Richtlinie zum Schutz von Kundendaten konfigurieren
Secundus Bank ist der Autor und Betreiber der Arbeitslast und verantwortlich für:
- Einrichtung der erforderlichen Ressourcen zum Speichern des Ergebnisses.
- Code für die Arbeitslast schreiben
- Veröffentlichen Sie das Arbeitslast-Image.
- Die Arbeitslast wird in einem Confidential Space mit Unterstützung für signierte Container-Images ausgeführt.
Die Secundus Bank entwickelt und veröffentlicht eine Arbeitslast, mit der Kundendaten abgefragt werden, die in einem Cloud Storage-Bucket gespeichert sind und der Primus Bank gehören. Die Primus Bank prüft die Arbeitslast, signiert das Container-Image und konfiguriert WIP-Richtlinien, um den Zugriff auf ihre Daten durch genehmigte Arbeitslasten zu ermöglichen. Das Ergebnis dieser Arbeitslastausführung wird in einem Cloud Storage-Bucket gespeichert, der der Secundus-Bank gehört.
Ressourcen für die Einrichtung eines Confidential Space
In diesem Codelab wird auf eine Reihe von Variablen verwiesen, die Sie auf die entsprechenden Werte für Ihr GCP-Projekt festlegen sollten. Bei den Befehlen in diesem Codelab wird davon ausgegangen, dass diese Variablen festgelegt wurden. So kann beispielsweise export PRIMUS_INPUT_STORAGE_BUCKET='my-input-bucket'
verwendet werden, um den Namen des Eingabespeicher-Buckets der Primus-Bank festzulegen. Wenn die Variablen der Ressourcennamen nicht festgelegt wurden, werden sie anhand der GCP-Projekt-ID generiert.
Konfiguriere im Primus-Projekt Folgendes:
$PRIMUS_INPUT_STORAGE_BUCKET
: Der Bucket, in dem die Kundendatendatei gespeichert ist.$PRIMUS_WORKLOAD_IDENTITY_POOL
: den Workload Identity-Pool (WIP), der Ansprüche validiert.$PRIMUS_WIP_PROVIDER
: Der Anbieter des Workload Identity-Pools, der die Autorisierungsbedingung für vom Attestation Verifier Service signierte Tokens enthält.$PRIMUS_SERVICEACCOUNT
: Das Dienstkonto, mit dem$PRIMUS_WORKLOAD_IDENTITY_POOL
auf die geschützten Ressourcen zugreift. 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
gespeicherten Daten verwendet wird.
In diesem Codelab neu:
$PRIMUS_COSIGN_REPOSITORY
: die Artifact Registry zum Speichern von Arbeitslast-Imagesignaturen$PRIMUS_SIGNING_KEY
: Der KMS-Schlüssel, mit dem der Prüfer/Datenmitarbeiter das Arbeitslast-Image signiert hat (z. B. Primus Bank in diesem Fall).
Konfigurieren Sie im Secundus-Projekt Folgendes:
$SECUNDUS_ARTIFACT_REGISTRY
: Die Artifact Registry, in die das Docker-Image der Arbeitslast gepusht wird.$WORKLOAD_IMAGE_NAME
: der Name des Docker-Images der Arbeitslast.$WORKLOAD_IMAGE_TAG
: das Tag des Docker-Images der Arbeitslast.$WORKLOAD_SERVICEACCOUNT
: Das Dienstkonto, das auf die vertrauliche VM zugreifen darf, auf der die Arbeitslast ausgeführt wird.$SECUNDUS_RESULT_BUCKET
: Der Bucket, in dem die Ergebnisse der Arbeitslast gespeichert werden.
Weitere Ressourcen:
primus_customer_list.csv
enthält die Kundendaten. Wir laden diese Daten in$PRIMUS_INPUT_STORAGE_BUCKET
hoch und erstellen eine Arbeitslast, mit der diese Daten abgefragt werden.
Vorhandener Workflow
Wenn Sie die Arbeitslast in Confidential Space ausführen, wird der folgende Prozess mit den konfigurierten Ressourcen ausgeführt:
- Die Arbeitslast fordert ein allgemeines Google-Zugriffstoken für die
$PRIMUS_SERVICEACCOUNT
vom WIP an. Es bietet ein Attestation Verifier-Diensttoken mit Workload- und Umgebungsansprüchen. - Wenn die Ansprüche für die Arbeitslastmessung im Attestation Verifier-Diensttoken mit der Attributbedingung in der WIP übereinstimmen, wird das Zugriffstoken für
$PRIMUS_SERVICEACCOUNT.
zurückgegeben. - Die Arbeitslast verwendet das Dienstkonto-Zugriffstoken, das mit
$PRIMUS_SERVICEACCOUNT
verknüpft ist, um auf die Kundendaten im Bucket$PRIMUS_INPUT_STORAGE_BUCKET
zuzugreifen. - Die Arbeitslast führt einen Vorgang auf diesen Daten aus.
- Die Arbeitslast verwendet das Dienstkonto
$WORKLOAD_SERVICEACCOUNT
, um die Ergebnisse dieses Vorgangs in den Bucket$SECUNDUS_RESULT_STORAGE_BUCKET
zu schreiben.
Neuer Workflow mit Unterstützung für signierte Container
Die Unterstützung für signierte Container wird in den vorhandenen Workflow integriert, wie unten dargestellt. Wenn Sie die Arbeitslast in einem Confidential Space mit Unterstützung für signierte Container-Images ausführen, wird der folgende Prozess mit den konfigurierten Ressourcen ausgeführt:
- Confidential Space erkennt alle Containersignaturen, die sich auf das derzeit ausgeführte Arbeitslast-Image beziehen, und sendet sie an den Attestierungsprüfer. Der Attestierungsprüfer überprüft die Signatur und nimmt alle gültigen Signaturen in die Attestierungsanträge auf.
- Die Arbeitslast fordert ein allgemeines Google-Zugriffstoken für die
$PRIMUS_SERVICEACCOUNT
vom WIP an. Es bietet ein Attestation Verifier-Diensttoken mit Workload- und Umgebungsansprüchen. - Wenn die Containersignatur-Anforderung im Attestation Verifier-Diensttoken mit der Attributbedingung in der WIP übereinstimmt, wird das Zugriffstoken für
$PRIMUS_SERVICEACCOUNT
zurückgegeben. - Die Arbeitslast verwendet das mit
$PRIMUS_SERVICEACCOUNT
verknüpfte Dienstkonto-Zugriffstoken, um auf die Kundendaten im Bucket$PRIMUS_INPUT_STORAGE_BUCKET
zuzugreifen. - Die Arbeitslast führt einen Vorgang auf diesen Daten aus.
- Die Arbeitslast verwendet
$WORKLOAD_SERVICEACCOUNT
, um die Ergebnisse dieses Vorgangs in den Bucket$SECUNDUS_RESULT_STORAGE_BUCKET
zu schreiben.
2. Cloud-Ressourcen einrichten
Im Rahmen der Einrichtung von Confidential Space erstellen Sie zuerst die erforderlichen Cloud-Ressourcen in den GCP-Projekten der Primus- und Secundus-Bank. In diesem Codelab werden die folgenden neuen Ressourcen verwendet:
Im Primus-Projekt:
- KMS-Signaturschlüssel, der zum Signieren von Secundus-Arbeitslasten nach der Prüfung des Codes verwendet wird.
- Artifact Registry-Repository zum Speichern der Cosignatursignaturen.
Im Secundus-Projekt gibt es keine neuen Ressourcen. Nachdem Sie diese Ressourcen eingerichtet haben, erstellen Sie ein Dienstkonto für die Arbeitslast mit den erforderlichen Rollen und Berechtigungen. Sie erstellen dann ein Arbeitslast-Image und der Prüfer, die Primus-Bank, signiert das Arbeitslast-Image. Die Arbeitslast wird dann von Datenbearbeitern (in diesem Codelab die Primus-Bank) autorisiert und der Arbeitslast-Betreiber (in diesem Fall die Secundus-Bank) führt die Arbeitslast aus.
Im Rahmen der Einrichtung von Confidential Space erstellen Sie die erforderlichen Cloud-Ressourcen in den GCP-Projekten Primus und Secundus.
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
- Wechseln Sie in das Verzeichnis für dieses Codelab.
cd confidential-space/codelabs/signed_container_codelab/scripts
- Achten Sie darauf, dass Sie die erforderlichen Projekte wie unten dargestellt eingerichtet haben.
export PRIMUS_PROJECT_ID=<GCP project id of primus bank>
export SECUNDUS_PROJECT_ID=<GCP project id of secundus bank>
- Legen Sie mit diesem Befehl die Variablen für die oben genannten Ressourcennamen fest. Sie können die Ressourcennamen mithilfe dieser Variablen (z. B.
export PRIMUS_INPUT_STORAGE_BUCKET='my-input-bucket'
) überschreiben. - 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
- Installieren Sie cosign gemäß der Anleitung hier.
Primus-Bankressourcen einrichten
In diesem Schritt richten Sie die erforderlichen Cloud-Ressourcen für die Primus-Bank ein. Führen Sie das folgende Script aus, um die Ressourcen für die Primus-Bank einzurichten. Dabei werden die folgenden Ressourcen erstellt:
- 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 Datendatei der Primus-Bank. - Workload Identity-Pool (
$PRIMUS_WORKLOAD_IDENTITY_POOL
) zur Validierung von Ansprüchen anhand von Attributebedingungen, die beim Anbieter konfiguriert wurden. - Dienstkonto (
$PRIMUS_SERVICEACCOUNT
), das mit dem oben genannten Workload Identity Pool ($PRIMUS_WORKLOAD_IDENTITY_POOL
) verknüpft ist, mit folgendem IAM-Zugriff: roles/cloudkms.cryptoKeyDecrypter
, um die Daten mit dem KMS-Schlüssel zu entschlüsseln.objectViewer
, um Daten aus dem Cloud Storage-Bucket zu lesen.roles/iam.workloadIdentityUser
, um dieses Dienstkonto mit dem Workload Identity-Pool zu verbinden.
./setup_primus_bank_resources.sh
Secundus-Bankressourcen einrichten
In diesem Schritt richten Sie die erforderlichen Cloud-Ressourcen für die Secundus-Bank ein. Führen Sie das folgende Script aus, um die Ressourcen für die Secundus-Bank einzurichten. Im Rahmen dieser Schritte werden die folgenden Ressourcen erstellt:
- Cloud Storage-Bucket (
$SECUNDUS_RESULT_STORAGE_BUCKET
) zum Speichern des Ergebnisses der Arbeitslastausführung durch die Secundus-Bank.
./setup_secundus_bank_resources.sh
3. Workload erstellen und signieren
Dienstkonto für Arbeitslast erstellen
Jetzt erstellen Sie ein Dienstkonto für die Arbeitslast mit den erforderlichen Rollen und Berechtigungen. Führen Sie das folgende Script aus, um ein Arbeitslastdienstkonto im Projekt der Secundus-Bank zu erstellen. Dieses Dienstkonto wird von der VM verwendet, auf der die Arbeitslast ausgeführt wird.
- Dieses Workload-Dienstkonto (
$WORKLOAD_SERVICEACCOUNT
) hat die folgenden Rollen: confidentialcomputing.workloadUser
, um ein Attestierungstoken zu erhaltenlogging.logWriter
, um Protokolle in Cloud Logging zu schreiben.objectViewer
, um Daten aus dem Cloud Storage-Bucket$PRIMUS_INPUT_STORAGE_BUCKET
zu lesen.objectAdmin
, um das Arbeitslastergebnis in den Cloud Storage-Bucket$SECUNDUS_RESULT_STORAGE_BUCKET
zu schreiben.
./create_workload_serviceaccount.sh
Arbeitslast erstellen
In diesem Schritt erstellen Sie ein Docker-Image für die Arbeitslast. Die in diesem Codelab verwendete Arbeitslast ist eine einfache Befehlszeilen-basierte Go-Anwendung, die Kunden (aus den Kundendaten der Primus-Bank) anhand eines angegebenen geografischen Standorts im Argument zählt. 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(
$SECUNDUS_ARTIFACT_REGISTRY
) für die Secundus-Bank. - Aktualisieren Sie den Arbeitslastcode mit den Namen der erforderlichen Ressourcen. Hier finden Sie den Code für die Arbeitslast, der in diesem Codelab verwendet wird.
- Erstellen Sie ein Go-Binary und ein Dockerfile, um ein Docker-Image des Arbeitslastcodes zu erstellen. Hier finden Sie das Dockerfile, das für dieses Codelab verwendet wird.
- Erstellen Sie das Docker-Image und veröffentlichen Sie es in der Artifact Registry (
$SECUNDUS_ARTIFACT_REGISTRY
) der Secundus Bank. - Gewähren Sie
$WORKLOAD_SERVICEACCOUNT
die Leseberechtigung für$SECUNDUS_ARTIFACT_REGISTRY
. Dies ist erforderlich, damit der Arbeitslastcontainer das Docker-Image der Arbeitslast aus der Artifact Registry abrufen kann.
./create_workload.sh
Arbeitslast signieren
Wir verwenden Cosign, um das Arbeitslast-Image zu signieren. Cosign speichert Signaturen standardmäßig im selben Repository wie das Image, das signiert wird. Wenn Sie ein anderes Repository für Signaturen angeben möchten, können Sie die Umgebungsvariable COSIGN_REPOSITORY
festlegen.
Hier verwenden wir Artifact Registry als Beispiel. Sie können auch andere OCI-basierte Register wie Docker Hub oder AWS CodeArtifact auswählen.
- Erstellen Sie ein Artifact Registry-Docker-Repository.
gcloud config set project $PRIMUS_PROJECT_ID
gcloud artifacts repositories create $PRIMUS_COSIGN_REPOSITORY \
--repository-format=docker --location=${PRIMUS_PROJECT_REPOSITORY_REGION}
- Erstellen Sie unter KMS einen Schlüsselbund und einen Schlüssel zum Signieren eines Arbeitslast-Images.
gcloud config set project $PRIMUS_PROJECT_ID
gcloud kms keyrings create $PRIMUS_SIGNING_KEYRING \
--location=${PRIMUS_PROJECT_LOCATION}
gcloud kms keys create $PRIMUS_SIGNING_KEY \
--keyring=$PRIMUS_SIGNING_KEYRING \
--purpose=asymmetric-signing \
--default-algorithm=ec-sign-p256-sha256 \
--location=${PRIMUS_PROJECT_LOCATION}
- Für Artifact Registry wird ein vollständiger Image-Name wie
$LOCATION/$PROJECT/$REPOSITORY/$IMAGE_NAME
erwartet. Sie können beliebige Container-Images zum Speichern von Signaturen in das Repository hochladen.
export COSIGN_REPOSITORY=us-docker.pkg.dev/${PRIMUS_PROJECT_ID}/${PRIMUS_COSIGN_REPOSITORY}/demo
- Weisen Sie dem Dienstkonto
$WORKLOAD_SERVICEACCOUNT
die Rolle „Betrachter“ für das Repository$PRIMUS_COSIGN_REPOSITORY
zu. So kann Confidential Space alle Container-Image-Signaturen erkennen, die in die$PRIMUS_COSIGN_REPOSITORY
hochgeladen wurden.
gcloud artifacts repositories add-iam-policy-binding ${PRIMUS_COSIGN_REPOSITORY} \
--project=${PRIMUS_PROJECT_ID} --role='roles/viewer' --location=us \
--member="serviceAccount:${WORKLOAD_SERVICEACCOUNT}@${SECUNDUS_PROJECT_ID}.iam.gserviceaccount.com"
Cosign ist ein leistungsstarkes Tool mit mehreren Signaturfunktionen. Für unseren Anwendungsfall muss Cosign nur mit einem Schlüsselpaar signieren. Die Cosignatur ohne Schlüssel wird für diese Funktion für signierte Container-Images nicht unterstützt.
Wenn Sie mit einem Schlüsselpaar signieren, haben Sie zwei Möglichkeiten:
- Signieren Sie mit einem lokalen Schlüsselpaar, das von Cosign generiert wurde.
- Signieren Sie mit einem Schlüsselpaar, das an anderer Stelle gespeichert ist (z. B. in einem KMS).
- Generieren Sie ein Schlüsselpaar in Cosign, falls Sie noch keines haben. Weitere Informationen finden Sie unter Apps mit selbst verwalteten Schlüsseln signieren. Hier haben wir beide Möglichkeiten (lokal und mit KMS-Anbieter) zum Generieren eines Schlüsselpaars und Signieren der Arbeitslast angegeben. Bitte folgen Sie einer dieser Möglichkeiten, um den Arbeitslastcontainer zu signieren.
// Set Application Default Credentials.
gcloud auth application-default login
// Generate keys using a KMS provider.
cosign generate-key-pair --kms <provider>://<key>
// Generate keys using Cosign.
cosign generate-key-pair
Ersetzen Sie oben <provider>://<key> durch gcpkms://projects/$PRIMUS_PROJECT_ID/locations/global/keyRings/$PRIMUS_SIGNING_KEYRING/cryptoKeys/$PRIMUS_SIGNING_KEY/cryptoKeyVersions/$PRIMUS_SIGNING_KEYVERSION
.
- <provider> : Bezieht sich auf die von Ihnen verwendete KMS-Lösung.
- <key> : Verweist auf den Schlüsselpfad in KMS.
- Rufen Sie den öffentlichen Schlüssel zur Überprüfung ab.
// For KMS providers.
cosign public-key --key <some provider>://<some key> > pub.pem
// For local key pair signing.
cosign public-key --key cosign.key > pub.pem
- Unterzeichnen Sie die Arbeitslast mit Cosign. Führen Sie eine nicht aufgefüllte Base64-Codierung des öffentlichen Schlüssels durch.
PUB=$(cat pub.pem | openssl base64)
// Remove spaces and trailing "=" signs.
PUB=$(echo $PUB | tr -d '[:space:]' | sed 's/[=]*$//')
- Signieren Sie die Arbeitslast mit Cosign und hängen Sie den exportierten öffentlichen Schlüssel und die Signaturalgorithmen an.
IMAGE_REFERENCE=us-docker.pkg.dev/$SECUNDUS_PROJECT_ID/$SECUNDUS_ARTIFACT_REPOSITORY/$WORKLOAD_IMAGE_NAME:$WORKLOAD_IMAGE_TAG
// Sign with KMS support.
cosign sign --key <some provider>://<some key> $IMAGE_REFERENCE \
-a dev.cosignproject.cosign/sigalg=ECDSA_P256_SHA256 \
-a dev.cosignproject.cosign/pub=$PUB
// Sign with a local key pair.
cosign sign --key cosign.key $IMAGE_REFERENCE \
-a dev.cosignproject.cosign/sigalg=ECDSA_P256_SHA256 \
-a dev.cosignproject.cosign/pub=$PUB
--key
[ERFORDERLICH] gibt an, welcher Signaturschlüssel verwendet werden soll. Wenn Sie sich auf einen von einem KMS-Anbieter verwalteten Schlüssel beziehen, verwenden Sie bitte das spezifische URI-Format aus der KMS-Unterstützung von Sigstore. Verwenden Sie stattdessen „cosign.key“, wenn Sie sich auf einen von Cosign generierten Schlüssel beziehen.$IMAGE_REFERENCE
[ERFORDERLICH] gibt an, welches Container-Image signiert werden soll. Das Format vonIMAGE_REFERENCE
kann durch das Tag oder den Image-Digest identifiziert werden. Beispiel:us-docker.pkg.dev/$SECUNDUS_PROJECT_ID/secundus-workloads/workload-container:latest or us-docker.pkg.dev/$SECUNDUS_PROJECT_ID/secundus-workloads/workload-container
[IMAGE-digest]
- Mit „-a“ [ERFORDERLICH] werden Anmerkungen angegeben, die an die Signaturnutzlast angehängt sind. Bei signierten Container-Images für Confidential Space müssen Public-Key- und Signaturalgorithmen an die Signaturnutzlast angehängt werden.
- Für
dev.cosignproject.cosign/sigalg
sind NUR drei Werte zulässig: - RSASSA_PSS_SHA256: RSASSA-Algorithmus mit PSS-Padding mit einem SHA256-Digest.
- RSASSA_PKCS1V15_SHA256: RSASSA-Algorithmus mit PKCS#1 v1.5-Padding mit einem SHA256-Digest.
- ECDSA_P256_SHA256: ECDSA auf der P-256-Kurve mit einem SHA256-Digest. Dies ist auch der Standardsignaturalgorithmus für von Cosign generierte Schlüsselpaare.
- Signaturen in das Docker-Repository hochladen
Mit Cosign sign werden Unterschriften automatisch in die angegebene COSIGN_REPOSITORY.
hochgeladen.
4. Arbeitslast autorisieren und ausführen
Arbeitslast autorisieren
In diesem Schritt richten wir den Workload Identity-Anbieter unter dem Workload Identity-Pool ($PRIMUS_WORKLOAD_IDENTITY_POOL
) ein. Für die Workload-Identität sind Attributbedingungen konfiguriert, wie unten dargestellt. Eine der Bedingungen besteht darin, den Fingerabdruck der Arbeitslast-Imagesignatur mit dem Fingerabdruck des Signatur-öffentlichen Schlüssels zu validieren. Wenn die Secundus Bank mit dieser Attributbedingung ein neues Arbeitslast-Image veröffentlicht, prüft die Primus Bank den Arbeitslastcode und signiert das neue Arbeitslast-Image, ohne die WIP-Richtlinie mit dem Image-Digest aktualisieren zu müssen.
gcloud config set project $PRIMUS_PROJECT_ID
PUBLIC_KEY_FINGERPRINT=$(openssl pkey -pubin -in pub.pem -outform DER | openssl sha256 | cut -d' ' -f2)
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
&& '${WORKLOAD_SERVICEACCOUNT}@${SECUNDUS_PROJECT_ID}.iam.gserviceaccount.com' in
assertion.google_service_accounts
&& ['ECDSA_P256_SHA256:${PUBLIC_KEY_FINGERPRINT}']
.exists(fingerprint, fingerprint in assertion.submods.container.image_signatures.map(sig,sig.signature_algorithm+':'+sig.key_id))"
Arbeitslast ausführen
In diesem Schritt führen wir die Arbeitslast auf einer Confidential VM aus. Erforderliche TEE-Argumente werden mit dem Metadaten-Flag übergeben. Argumente für den Arbeitslastcontainer werden über den Teil „tee-cmd
“ des Flags übergeben. Die Arbeitslast ist so codiert, dass das Ergebnis in $SECUNDUS_RESULT_STORAGE_BUCKET
veröffentlicht wird.
gcloud compute instances create ${WORKLOAD_VM} \
--confidential-compute-type=SEV \
--shielded-secure-boot \
--maintenance-policy=MIGRATE \
--scopes=cloud-platform \
--zone=${SECUNDUS_PROJECT_ZONE} \
--project=${SECUNDUS_PROJECT_ID} \
--image-project=confidential-space-images \
--image-family=confidential-space \
--service-account=${WORKLOAD_SERVICEACCOUNT}@${SECUNDUS_PROJECT_ID}.iam.gserviceaccount.com \
--metadata "^~^tee-image-reference=us-docker.pkg.dev/${SECUNDUS_PROJECT_ID}/${SECUNDUS_ARTIFACT_REPOSITORY}/${WORKLOAD_IMAGE_NAME}:${WORKLOAD_IMAGE_TAG}~tee-restart-policy=Never~tee-cmd="[\"count-location\",\"Seattle\",\"gs://${SECUNDUS_RESULT_STORAGE_BUCKET}/seattle-result\"]"~tee-signed-image-repos=us-docker.pkg.dev/${PRIMUS_PROJECT_ID}/${PRIMUS_COSIGN_REPOSITORY}/demo"
Ergebnisse ansehen
Sehen Sie sich die Ergebnisse der Arbeitslast im Secundus-Projekt an.
gcloud config set project $SECUNDUS_PROJECT_ID
gsutil cat gs://$SECUNDUS_RESULT_STORAGE_BUCKET/seattle-result
Das Ergebnis sollte 3
sein, da so viele Personen aus Seattle in der Datei primus_customer_list.csv
aufgeführt sind.
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:
- Eingabespeicher-Bucket der Primus-Bank (
$PRIMUS_INPUT_STORAGE_BUCKET
). - Primus-Bankdienstkonto (
$PRIMUS_SERVICEACCOUNT
) - Artifact Registry der Primus Bank, die Bildsignaturen enthält (
$PRIMUS_COSIGN_REPOSITORY
). - Workload Identity-Pool der Primus Bank (
$PRIMUS_WORKLOAD_IDENTITY_POOL
) - Arbeitslastdienstkonto der Secundus Bank (
$WORKLOAD_SERVICEACCOUNT
) - Compute-Instanz der Arbeitslast
- Ergebnisspeicher-Bucket der Secundus Bank (
$SECUNDUS_RESULT_STORAGE_BUCKET
). - Artifact Registry der Secundus Bank (
$SECUNDUS_ARTIFACT_REGISTRY
) - Arbeitslast-VM der Secundus Bank (
$WORKLOAD_VM
)
./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 die Funktion für signierte Container-Images nutzen, um die Nutzerfreundlichkeit von Confidential Space zu verbessern.
Was liegt als Nächstes an?
Sehen Sie sich diese ähnlichen Codelabs an:
- Geschützte freigegebene Daten, die in Confidential Space verwendet werden
- 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