Codelab für signierte Container-Images

1. Übersicht

Dieses Codelab baut auf dem Codelab „Confidential Space“ auf. Unterstützung für signierte Container-Images mit der Option, einen Container mit einem attestierten öffentlichen Schlüssel zu authentifizieren, anstatt einen Image-Digest in der WIP-Richtlinie (Workload Identity Pool) anzugeben.

Was sich durch die Unterstützung signierter Container-Images im Confidential Space geändert hat:

Verbesserte Nutzerfreundlichkeit:Mit der Einführung der Funktion für signierte Container-Images können wir jetzt vom Arbeitslast-Image-Digest-Ansatz zum Containersignaturansatz für Mitbearbeiter/Prüfer wechseln, die ein Image autorisieren.

  • Bei der direkten Verwendung von Image-Digests müssen Ressourceninhaber ihre Richtlinien jedes Mal mit einem Image-Digest aktualisieren, wenn sie ein neues Image autorisieren. Durch die Verwendung von Image-Signaturen enthält die Richtlinie einen Fingerabdruck eines öffentlichen Schlüssels, dessen zugehöriger privater Schlüssel dem Mitbearbeiter/Auditor gehört und zum Signieren der geprüften Bilder verwendet wird.
  • Bei einigen Sicherheitsmodellen ist es praktischer, auf einen vertrauenswürdigen Image-Signaturschlüssel zu verweisen, als eine Liste neuer Image-Digest-Werte zu aktualisieren.

Keine Regression der Sicherheit:Bei diesem Ansatz für die Containersignatur kommt es nicht zu einem Sicherheitsabfall gegenüber dem vorherigen Image-Digest-Ansatz, da die Vertrauensgrenzen gleich bleiben. Bei der Containersignatur autorisiert der Ressourceninhaber einen Verifizierungsschlüssel, indem er den vertrauenswürdigen öffentlichen Schlüssel-Fingerabdruck in der WIP-Richtlinie angibt. Die Autorisierungsprüfung wird vom Attestation Verifier Service und WIP durchgeführt. Der Attestation Verifier Service überprüft, ob die Signatur mit der laufenden Arbeitslast verknüpft ist, und die WIP-Richtlinie prüft, ob der vom Dienst geltend gemachte öffentliche Schlüssel durch eine Richtlinie autorisiert ist.

Starke Sicherheit: Die Verwendung von Container-Image-Signaturen ermöglicht es, ein gewisses Maß an Vertrauen an den Image-Signaturgeber zu delegieren. Durch Angabe des öffentlichen Schlüssel-Fingerabdrucks eines vertrauenswürdigen Unterzeichners in der Attestierungsrichtlinie autorisiert der Ressourceninhaber diesen Unterzeichner, Empfehlungen zu geben, welche Container-Images einer Richtlinie entsprechen. Der Attestation Verifier Service überprüft, ob die Signatur der laufenden Arbeitslast zugeordnet ist, und die Richtlinie prüft, ob der öffentliche Schlüssel, mit dem die Signatur erstellt wurde, durch eine Richtlinie autorisiert ist. Dadurch erhalten die Bildsignaturen zusätzliche Indirektionsmöglichkeiten, die die hohen Sicherheitsstandards von Confidential Space erhalten.

Der einzige Unterschied zwischen diesen Ansätzen besteht darin, dass der letztere Ansatz eine zusätzliche Indirektionsebene verwendet, 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:

  • So signieren Sie ein geprüftes Container-Image mit Cosign
  • Container-Image-Signaturen in OCI-Registries hochladen, um Signaturen zu erkennen und zu speichern
  • Erforderliche Cloud-Ressourcen zum Ausführen von Confidential Space 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 ein Container-Image, das von einem vertrauenswürdigen Schlüssel signiert ist, der in Google Compute Engine ausgeführt wird, per Fernzugriff attestieren können.

Voraussetzungen

Rollen in einem Confidential Space mit signiertem Container-Image

In diesem Codelab ist die Primus Bank der Prüfer und der Ressourceninhaber, der für Folgendes verantwortlich ist:

  1. Erforderliche Ressourcen mit Beispieldaten einrichten
  2. Arbeitslastcode prüfen.
  3. Mit cosign das Arbeitslast-Image signieren.
  4. Signatur in ein Repository hochladen
  5. WIP-Richtlinie zum Schutz von Kundendaten wird konfiguriert.

Die Secundus Bank ist Autor und Betreiber von Arbeitslasten und ist verantwortlich für:

  1. Erforderliche Ressourcen zum Speichern des Ergebnisses werden eingerichtet.
  2. Arbeitslastcode wird geschrieben.
  3. Arbeitslast-Image veröffentlichen.
  4. Arbeitslast in Confidential Space mit Unterstützung von signierten Container-Images ausführen.

Die Secundus Bank entwickelt und veröffentlicht eine Arbeitslast, die Kundendaten abfragt, 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 der Secundus Bank gespeichert.

Ressourcen für die Einrichtung von Confidential Space

In diesem Codelab wird auf eine Reihe von Variablen verwiesen, für die Sie 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 mit export PRIMUS_INPUT_STORAGE_BUCKET='my-input-bucket' der Name des Eingabe-Storage-Buckets der Primus Bank festgelegt werden. Wenn Variablen für die Ressourcennamen nicht festgelegt wurden, werden sie basierend auf der GCP-Projekt-ID generiert.

Konfigurieren Sie im Primus-Projekt Folgendes:

  • $PRIMUS_INPUT_STORAGE_BUCKET: Der Bucket, in dem die Datei mit den Kundendaten gespeichert ist.
  • $PRIMUS_WORKLOAD_IDENTITY_POOL: der Workload Identity-Pool (WIP), der Anforderungen validiert.
  • $PRIMUS_WIP_PROVIDER: der Workload Identity-Poolanbieter, der die Autorisierungsbedingung für Tokens enthält, die vom Attestation Verifier Service signiert wurden.
  • $PRIMUS_SERVICEACCOUNT: Das Dienstkonto, das $PRIMUS_WORKLOAD_IDENTITY_POOL für den Zugriff auf die geschützten Ressourcen verwendet. In diesem Schritt hat er die Berechtigung, die im Bucket $PRIMUS_INPUT_STORAGE_BUCKET gespeicherten Kundendaten aufzurufen.
  • $PRIMUS_ENC_KEY: der KMS-Schlüssel, der zum Verschlüsseln der in $PRIMUS_INPUT_STORAGE_BUCKET gespeicherten Daten verwendet wird.

Ressourcen, die neu in diesem Codelab sind:

  • $PRIMUS_COSIGN_REPOSITORY: Artifact Registry zum Speichern von Arbeitslast-Image-Signaturen.
  • $PRIMUS_SIGNING_KEY: der KMS-Schlüssel, der zum Signieren des Arbeitslast-Images von Prüfer/Daten-Mitbearbeitern verwendet wird (in diesem Fall z. B. „Primeus Bank“).

Konfigurieren Sie im Secundus-Projekt Folgendes:

  • $SECUNDUS_ARTIFACT_REGISTRY: die Artefakt-Registry, in die das Docker-Image der Arbeitslast übertragen wird.
  • $WORKLOAD_IMAGE_NAME: der Name des Docker-Images der Arbeitslast.
  • $WORKLOAD_IMAGE_TAG: Tag des Docker-Images der Arbeitslast.
  • $WORKLOAD_SERVICEACCOUNT: das Dienstkonto mit der Berechtigung für den Zugriff auf die Confidential VM, 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, die diese Daten abfragt.

Vorhandener Workflow

Wenn Sie die Arbeitslast in Confidential Space ausführen, wird der folgende Prozess mit den konfigurierten Ressourcen ausgeführt:

  1. Die Arbeitslast fordert ein allgemeines Google-Zugriffstoken für $PRIMUS_SERVICEACCOUNT von WIP an. Sie bietet ein Diensttoken für die Attestierungsprüfung mit Arbeitslast- und Umgebungsanforderungen.
  2. Wenn die Anforderungen der Arbeitslastmessung im Service-Token des Attestation Verifier Service mit der Attributbedingung im WIP übereinstimmen, wird das Zugriffstoken für $PRIMUS_SERVICEACCOUNT. zurückgegeben.
  3. Die Arbeitslast verwendet das mit $PRIMUS_SERVICEACCOUNT verknüpfte Dienstkonto-Zugriffstoken, um auf die Kundendaten im Bucket $PRIMUS_INPUT_STORAGE_BUCKET zuzugreifen.
  4. Die Arbeitslast führt einen Vorgang mit diesen Daten aus.
  5. 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 von signierten Containern

Die Unterstützung des signierten Containers wird in den bestehenden Workflow eingebunden, wie unten hervorgehoben. Wenn Sie die Arbeitslast in Confidential Space mit Unterstützung von signierten Container-Images ausführen, wird der folgende Vorgang mit den konfigurierten Ressourcen ausgeführt:

  1. Confidential Space erkennt alle Containersignaturen im Zusammenhang mit dem aktuell ausgeführten Arbeitslast-Image und sendet sie an die Attestierungsprüfer. Die Attestierung prüft die Signatur und schließt alle gültigen Signaturen in die Attestierungsanforderungen ein.
  2. Die Arbeitslast fordert ein allgemeines Google-Zugriffstoken für $PRIMUS_SERVICEACCOUNT von WIP an. Sie bietet ein Diensttoken für die Attestierungsprüfung mit Arbeitslast- und Umgebungsanforderungen.
  3. Wenn die Containersignaturanforderungen im Service-Token des Attestation Verifier Service mit der Attributbedingung im WIP übereinstimmen, wird das Zugriffstoken für $PRIMUS_SERVICEACCOUNT zurückgegeben.
  4. Die Arbeitslast verwendet das mit $PRIMUS_SERVICEACCOUNT verknüpfte Dienstkonto-Zugriffstoken, um auf die Kundendaten im Bucket $PRIMUS_INPUT_STORAGE_BUCKET zuzugreifen.
  5. Die Arbeitslast führt einen Vorgang mit diesen Daten aus.
  6. Die Arbeitslast verwendet den $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 für die GCP-Projekte der Primus und Secundus Bank. Dies sind die neuen Ressourcen in diesem Codelab:

Im Primus-Projekt:

  • KMS-Signaturschlüssel, der nach der Codeprüfung zum Signieren von Secundus-Arbeitslasten verwendet wird.
  • Artifact Registry-Repository zum Speichern der Cosign-Signaturen.

Im Secundus-Projekt sind keine neuen Ressourcen vorhanden. Sobald diese Ressourcen eingerichtet sind, erstellen Sie ein Dienstkonto für die Arbeitslast mit den erforderlichen Rollen und Berechtigungen. Anschließend erstellen Sie ein Arbeitslast-Image und der Prüfer, die Primus Bank, signiert das Arbeitslast-Image. Die Arbeitslast wird dann von Daten-Mitbearbeitern (in diesem Codelab die Primus Bank) autorisiert und der Arbeitslastbetreiber (in diesem Fall Security Bank) führt die Arbeitslast aus.

Im Rahmen der Einrichtung von Confidential Space erstellen Sie die erforderlichen Cloud-Ressourcen in den GCP-Projekten von Primus und Secundus.

Hinweis

  • Klonen Sie dieses Repository mit dem folgenden Befehl, um die erforderlichen Skripts für dieses Codelab abzurufen.
$ git clone https://github.com/GoogleCloudPlatform/confidential-space
  • Achten Sie darauf, dass Sie die erforderlichen Projekte wie unten gezeigt festgelegt 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 mit diesen Variablen überschreiben (z. B. export PRIMUS_INPUT_STORAGE_BUCKET='my-input-bucket')
  • Führen Sie das folgende Skript aus, um die verbleibenden Variablennamen auf Werte festzulegen, die auf Ihrer Projekt-ID für Ressourcennamen basieren.
$ source config_env.sh

Primus-Bankressourcen einrichten

In diesem Schritt richten Sie die erforderlichen Cloud-Ressourcen für die Primus Bank ein. Führen Sie das folgende Skript aus, um die Ressourcen für die Primus Bank einzurichten. Im Rahmen dieser Schritte werden die folgenden Ressourcen erstellt:

  • Cloud Storage-Bucket ($PRIMUS_INPUT_STORAGE_BUCKET) zum Speichern der verschlüsselten Datei mit den Kundendaten 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), um Anforderungen anhand von Attributbedingungen zu validieren, die unter seinem Anbieter konfiguriert wurden.
  • Dienstkonto ($PRIMUS_SERVICEACCOUNT), das an den oben genannten Workload Identity-Pool ($PRIMUS_WORKLOAD_IDENTITY_POOL) mit folgendem IAM-Zugriff angehängt ist:
  • 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 zum Verbinden dieses Dienstkontos mit dem Workload Identity-Pool.
$ ./setup_primus_bank_resources.sh

Secundus Bank-Ressourcen einrichten

In diesem Schritt richten Sie die erforderlichen Cloud-Ressourcen für die Secundus Bank ein. Führen Sie das folgende Skript 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), um das Ergebnis der Arbeitslastausführung durch die Secundus Bank zu speichern.
$ ./setup_secundus_bank_resources.sh

3. Arbeitslast erstellen und signieren

Arbeitslastdienstkonto erstellen

Jetzt erstellen Sie ein Dienstkonto für die Arbeitslast mit den erforderlichen Rollen und Berechtigungen. Führen Sie das folgende Skript aus, um ein Arbeitslastdienstkonto im Secundus Bank-Projekt zu erstellen. Dieses Dienstkonto wird von der VM verwendet, auf der die Arbeitslast ausgeführt wird.

  • Dieses Arbeitslastdienstkonto ($WORKLOAD_SERVICEACCOUNT) hat die folgenden Rollen:
  • confidentialcomputing.workloadUser zum Abrufen eines Attestierungstokens
  • logging.logWriter, um Logs 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, CLI-basierte Go-App, die Kunden (aus Kundendaten der Primus Bank) an einem angegebenen geografischen Standort im Argument zählt. Führen Sie das folgende Skript aus, um eine Arbeitslast zu erstellen, in der die folgenden Schritte ausgeführt werden:

  • Erstellen Sie Artifact Registry($SECUNDUS_ARTIFACT_REGISTRY) der Secundus Bank.
  • Aktualisieren Sie den Arbeitslastcode mit den erforderlichen Ressourcennamen. Hier finden Sie den Arbeitslastcode, der für dieses Codelab verwendet wird.
  • Erstellen Sie ein Go-Binärprogramm und ein Dockerfile, um ein Docker-Image des Arbeitslastcodes zu erstellen. Das für dieses Codelab verwendete Dockerfile finden Sie hier.
  • Erstellen Sie das Docker-Image und veröffentlichen Sie es in der Artifact Registry ($SECUNDUS_ARTIFACT_REGISTRY) der Secundus Bank.
  • $WORKLOAD_SERVICEACCOUNT-Leseberechtigung für „$SECUNDUS_ARTIFACT_REGISTRY“ gewähren. Dies ist erforderlich, damit der Arbeitslastcontainer das Docker-Image der Arbeitslast aus 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 je nach Präferenz auch andere OCI-basierte Registrys wie Docker Hub und AWS CodeArtifact auswählen.

  1. 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=us
  1. Erstellen Sie unter KMS einen Schlüsselbund und einen Schlüssel, um ein Arbeitslast-Image zu signieren.
$ gcloud config set project $PRIMUS_PROJECT_ID

$ gcloud kms keyrings create $PRIMUS_SIGNING_KEYRING \
  --location=global

$ gcloud kms keys create $PRIMUS_SIGNING_KEY \
  --keyring=$PRIMUS_SIGNING_KEYRING \
  --purpose=asymmetric-signing \
  --default-algorithm=ec-sign-p256-sha256
  --location=us
  1. Für Artifact Registry wird ein vollständiger Image-Name wie $LOCATION/$PROJECT/$REPOSITORY/$IMAGE_NAME erwartet. Sie können ein beliebiges Container-Image in das Repository hochladen, um Signaturen zu speichern.
$ export COSIGN_REPOSITORY=us-docker.pkg.dev/${PRIMUS_PROJECT_ID}/${PRIMUS_COSIGN_REPOSITORY}/demo
  1. Gewähren Sie dem Dienstkonto $WORKLOAD_SERVICEACCOUNT die Rolle „Betrachter“ für das Repository $PRIMUS_COSIGN_REPOSITORY. So kann Confidential Space alle Container-Image-Signaturen erkennen, die in $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. In unserem Anwendungsfall muss Cosign nur mit einem Schlüsselpaar signiert werden. Das schlüssellose Signieren wird für diese Funktion für signierte Container-Images nicht unterstützt.

Beim Signieren mit einem Schlüsselpaar gibt es zwei Möglichkeiten:

  1. Mit einem von Cosign generierten lokalen Schlüsselpaar signieren.
  2. Signieren Sie sich mit einem Schlüsselpaar, das an einem anderen Ort gespeichert ist, z. B. in einem KMS.
  1. Generieren Sie ein Schlüsselpaar in Cosign, falls Sie noch keines haben. Weitere Informationen finden Sie unter Mit selbstverwalteten Schlüsseln 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 im obigen Beispiel <provider>://<key>. mit gcpkms://projects/$PRIMUS_PROJECT_ID/locations/global/keyRings/$PRIMUS_SIGNING_KEYRING/cryptoKeys/$PRIMUS_SIGNING_KEY/cryptoKeyVersions/$PRIMUS_SIGNING_KEYVERSION

  • &lt;provider&gt; Bezieht sich auf die von Ihnen verwendete KMS-Lösung.
  • &lt;key&gt; Bezieht sich auf den Schlüsselpfad in KMS.
  1. Rufen Sie den öffentlichen Schlüssel zur Bestätigung 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
  1. Signieren Sie die Arbeitslast mit Cosign. Base64-Codierung mit unpadding für den öffentlichen Schlüssel ausführen
$ PUB=$(cat pub.pem | openssl base64)

// Remove spaces and trailing "=" signs.
$ PUB=$(echo $PUB | tr -d '[:space:]' | sed 's/[=]*$//')
  1. Signieren Sie die Arbeitslast mit Cosign und dem exportierten öffentlichen Schlüssel und den Signaturalgorithmen.
$ 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 Schlüssel beziehen, der von einem KMS-Anbieter verwaltet wird, müssen Sie das spezifische URI-Format verwenden, das vom Sigstore KMS-Support bereitgestellt wird. Wenn Sie auf einen von Cosign generierten Schlüssel verweisen, verwenden Sie stattdessen cosign.key.
  • $IMAGE_REFERENCE [ERFORDERLICH] gibt an, welches Container-Image signiert werden soll. Das Format von IMAGE_REFERENCE kann durch ein Tag oder einen 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]
  • -a [ERFORDERLICH] gibt Anmerkungen an, die an die Signaturnutzlast angehängt sind. Für von Confidential Space signierte Container-Images müssen die Public-Key- und Signaturalgorithmen an die Signaturnutzlast angehängt werden.
  • dev.cosignproject.cosign/sigalg akzeptiert NUR drei Werte:
  • RSASSA_PSS_SHA256: RSASSA-Algorithmus mit PSS-Padding mit SHA256-Digest.
  • RSASSA_PKCS1V15_SHA256: RSASSA-Algorithmus mit PKCS#1 v1.5-Padding mit SHA256-Digest.
  • ECDSA_P256_SHA256: ECDSA auf der P-256-Kurve mit einem SHA256-Digest. Dies ist auch der Standard-Signaturalgorithmus für mit Cosign generierte Schlüsselpaare.
  1. Signaturen in das Docker-Repository hochladen

Durch das Cosignieren werden Signaturen automatisch in das angegebene COSIGN_REPOSITORY hochgeladen.

4. Arbeitslast autorisieren und ausführen

Arbeitslast autorisieren

In diesem Schritt richten wir den Workload Identity-Anbieter im Workload Identity-Pool ($PRIMUS_WORKLOAD_IDENTITY_POOL) ein. Für die Workload Identity wurden Attributbedingungen konfiguriert (siehe unten). Eine der Bedingungen besteht darin, den Fingerabdruck der Arbeitslast-Image-Signatur mit dem Fingerabdruck des öffentlichen Schlüssels zu vergleichen. Wenn die Secundus Bank ein neues Arbeitslast-Image veröffentlicht, prüft die Primus Bank mit dieser Attributbedingung 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 mit "tee-cmd" übergeben. -Teil der Kennzeichnung. Die Arbeitslast ist so codiert, dass das Ergebnis in $SECUNDUS_RESULT_STORAGE_BUCKET veröffentlicht wird.

$ gcloud config set project $SECUNDUS_PROJECT_ID

$ gcloud compute instances create signed-container-vm \
 --confidential-compute-type=SEV \
 --shielded-secure-boot \
 --maintenance-policy=TERMINATE \
 --scopes=cloud-platform --zone=us-west1-b \
 --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 im Secundus-Projekt die Ergebnisse der Arbeitslast 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 aufgelistet sind.

5. Bereinigen

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

  • Eingabe-Storage-Bucket der Primus-Bank ($PRIMUS_INPUT_STORAGE_BUCKET).
  • Primus-Bankdienstkonto ($PRIMUS_SERVICEACCOUNT).
  • Artefakte Registry der Primus Bank, die Image-Signaturen 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.
  • Storage-Bucket für Ergebnisse der Secundus Bank ($SECUNDUS_RESULT_STORAGE_BUCKET).
  • Artefakt-Registry der Secundus Bank ($SECUNDUS_ARTIFACT_REGISTRY).
// run the clean up script to delete the resources created as part of this codelab.
$ ./cleanup.sh

Wenn Sie die Untersuchung abgeschlossen haben, können 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 auf „Löschen“. oben: Dadurch wird das Projekt zum Löschen vorgemerkt.

Glückwunsch

Herzlichen Glückwunsch, du hast das Codelab erfolgreich abgeschlossen.

Sie haben gelernt, wie Sie mit der Funktion für signierte Container-Images die Nutzerfreundlichkeit von Confidential Space verbessern.

Was liegt als Nächstes an?

Sehen Sie sich einige dieser ähnlichen Codelabs an...

Weitere Informationen