Codelab für signierte Container-Images

1. Übersicht

Dieses Codelab basiert auf dem Codelab zu Confidential Space. Unterstützung für signierte Container-Images, da eine Option zum Authentifizieren eines Containers mit einem attestierten öffentlichen Schlüssel anstelle der Angabe des Image-Digest in der Workload Identity-Pool-Richtlinie (WIP) verfügbar ist.

Was hat sich bei der Unterstützung signierter Container-Images in Confidential Space geändert?

Verbesserte Nutzerfreundlichkeit:Mit der Einführung der Funktion für signierte Container-Images können wir jetzt von einem Arbeitslast-Image-Digest-Ansatz zu einem Container-Signatur-Ansatz für Mitarbeiter/Prüfer wechseln, die ein Image autorisieren.

Wenn Ressourceninhaber Bild-Digests direkt verwenden, müssen sie ihre Richtlinien jedes Mal mit einem Bild-Digest aktualisieren, wenn sie ein neues Bild autorisieren. Bei Verwendung von Image-Signaturen enthält die Richtlinie einen öffentlichen Schlüssel-Fingerabdruck, dessen entsprechender privater Schlüssel dem Mitarbeiter/Prüfer gehört und zum Signieren der geprüften Images verwendet wird.
Bei einigen Sicherheitsmodellen ist es einfacher, auf einen vertrauenswürdigen Bildsignaturschlüssel zu verweisen, als eine Liste mit neuen Bild-Digest-Werten zu aktualisieren.

Keine Sicherheitsbeeinträchtigung:Dieser Ansatz für die Containersignatur führt nicht zu einer Sicherheitsbeeinträchtigung im Vergleich zum vorherigen Ansatz mit dem Image-Digest, da die Vertrauensgrenzen gleich bleiben. Beim Ansatz mit der Containersignatur autorisiert der Ressourceninhaber einen Verifizierungsschlüssel, indem er den Fingerabdruck des vertrauenswürdigen öffentlichen Schlüssels in der WIP-Richtlinie angibt. Die Autorisierungsprüfung wird vom Attestation Verifier Service und WIP durchgeführt. Der Attestation Verifier Service prüft, ob die Signatur mit der ausgeführten Arbeitslast verknüpft ist, und die WIP-Richtlinie prüft, ob der vom Dienst bestätigte öffentliche Schlüssel durch die Richtlinie autorisiert ist.

Hohe Sicherheit:Durch die Verwendung von Container-Image-Signaturen kann ein gewisses Maß an Vertrauen an den Image-Signierer delegiert werden. Indem der Ressourceninhaber den Fingerabdruck des öffentlichen Schlüssels eines vertrauenswürdigen Signers in der Attestierungsrichtlinie angibt, autorisiert er diesen Signer, Empfehlungen dazu abzugeben, welche Container-Images einer Richtlinie entsprechen. Der Attestation Verifier Service prüft, ob die Signatur mit dem ausgeführten Workload verknüpft ist, und die Richtlinie prüft, ob der öffentliche Schlüssel, mit dem die Signatur erstellt wurde, durch die Richtlinie autorisiert ist. Dadurch wird die zusätzliche Indirektionsebene, die durch die Bildsignierung bereitgestellt wird, beibehalten und die hohen Sicherheitsgarantien von Confidential Space bleiben erhalten.

Der einzige Unterschied zwischen diesen Ansätzen besteht darin, dass beim zweiten Ansatz eine zusätzliche Ebene der Indirektion verwendet wird, bei der Arbeitslast-Images mit einem Signaturschlüssel autorisiert werden. Dadurch entstehen keine neuen Sicherheitslücken, da die Vertrauensgrenzen gleich bleiben.

Lerninhalte

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-Registries hochladen, damit sie erkannt und gespeichert werden können
Erforderliche Cloud-Ressourcen für die Ausführung 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 eine Remote-Attestierung für ein Container-Image durchführen, das mit einem vertrauenswürdigen Schlüssel signiert wurde und auf Google Compute Engine ausgeführt wird.

Voraussetzungen

Confidential Space-Codelab abschließen
Google Cloud Platform-Projekt
Ein Browser, z. B. Chrome oder Firefox
Erfahrung mit standardmäßigen Linux-Texteditoren wie vim, emacs oder nano
Grundkenntnisse zu Sigstore Cosign
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.
Grundkenntnisse in Artifact Registry
Grundkenntnisse zu digitalen Signaturen

Rollen in einem Confidential Space mit signiertem Container-Image

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

Einrichten der erforderlichen Ressourcen mit Beispieldaten.
Prüfung des Arbeitslastcodes.
cosign zum Signieren des Arbeitslast-Images verwenden.
Die Signatur in ein Repository hochladen.
Konfigurieren von WIP-Richtlinien zum Schutz von Kundendaten.

Die Secundus Bank ist der Autor und Betreiber der Arbeitslast und verantwortlich für:

Einrichten der erforderlichen Ressourcen zum Speichern des Ergebnisses.
Arbeitslastcode schreiben
Arbeitslast-Image veröffentlichen
Die Arbeitslast wird in 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 Workload-Ausführung wird in einem Cloud Storage-Bucket gespeichert, der der Secundus Bank gehört.

Ressourcen, die an der Einrichtung eines Confidential Space beteiligt sind

In diesem Codelab wird auf eine Reihe von Variablen verwiesen, die Sie auf geeignete Werte für Ihr GCP-Projekt festlegen sollten. Bei den Befehlen in diesem Codelab wird davon ausgegangen, dass diese Variablen festgelegt wurden. (z. B. kann export PRIMUS_INPUT_STORAGE_BUCKET='my-input-bucket' verwendet werden, um den Namen des Eingabe-Storage-Buckets der Primus Bank festzulegen). Wenn keine Variablen für die Ressourcennamen festgelegt wurden, werden sie anhand der GCP-Projekt-ID generiert.

Konfigurieren Sie Folgendes im Primus-Projekt:

$PRIMUS_INPUT_STORAGE_BUCKET: Der Bucket, in dem die Kundendatendatei gespeichert ist.
$PRIMUS_WORKLOAD_IDENTITY_POOL: Der Workload Identity-Pool (WIP), der Ansprüche validiert.
$PRIMUS_WIP_PROVIDER: Der Anbieter des Workload Identity-Pools, der die Autorisierungsbedingung für die Verwendung von 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 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 verwendet wird.

Neue Ressourcen in diesem Codelab:

$PRIMUS_COSIGN_REPOSITORY: Die Artifact Registry zum Speichern von Arbeitslast-Image-Signaturen.
$PRIMUS_SIGNING_KEY: Der KMS-Schlüssel, der zum Signieren des Arbeitslast-Images durch Prüfer/Datenmitbearbeiter verwendet wird (z. B. Primus Bank in diesem Fall).

Konfigurieren Sie im Secundus-Projekt Folgendes:

$SECUNDUS_ARTIFACT_REGISTRY: Die Artifact Registry, in die das Docker-Image für die Arbeitslast übertragen wird.
$WORKLOAD_IMAGE_NAME: Der Name des Docker-Images für die Arbeitslast.
$WORKLOAD_IMAGE_TAG: Das Tag des Docker-Images der Arbeitslast.
$WORKLOAD_SERVICEACCOUNT: Das Dienstkonto, das berechtigt ist, auf die Confidential VM zuzugreifen, 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 einen Arbeitslast, mit dem diese Daten abgefragt werden.

Vorhandener Workflow

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

Die Arbeitslast fordert ein allgemeines Google-Zugriffstoken für $PRIMUS_SERVICEACCOUNT aus dem WIP an. Es bietet ein Attestation Verifier-Diensttoken mit Ansprüchen für Arbeitslast und Umgebung.
Wenn die Ansprüche für die Arbeitslastmessung im Attestierungsprüfer-Diensttoken mit der Attributbedingung im 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.
Der Arbeitslast führt einen Vorgang für diese 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 bestehenden Workflow integriert, wie unten dargestellt. Wenn Sie die Arbeitslast in Confidential Space mit Unterstützung für signierte Container-Images ausführen, wird mit den konfigurierten Ressourcen der folgende Prozess ausgeführt:

Confidential Space erkennt alle Containersignaturen, die mit dem aktuell ausgeführten Arbeitslast-Image verknüpft sind, und sendet sie an den Attestierungsprüfer. Der Attestierungsprüfer überprüft die Signatur und fügt alle gültigen Signaturen in die Attestierungsansprüche ein.
Die Arbeitslast fordert ein allgemeines Google-Zugriffstoken für $PRIMUS_SERVICEACCOUNT aus dem WIP an. Es bietet ein Attestation Verifier-Diensttoken mit Ansprüchen für Arbeitslast und Umgebung.
Wenn die Container-Signaturansprüche im Attestation Verifier-Diensttoken mit der Attributbedingung im 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 $PRIMUS_INPUT_STORAGE_BUCKET-Bucket zuzugreifen.
Der Arbeitslast führt einen Vorgang für diese 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. Folgende Ressourcen sind neu in diesem Codelab:

Im Primus-Projekt:

KMS-Signierschlüssel, der zum Signieren von Secundus-Arbeitslasten verwendet wird, nachdem der Code geprüft wurde.
Artifact Registry-Repository zum Speichern der Cosign-Signaturen.

Im Secundus-Projekt gibt es keine neuen Ressourcen. Nachdem 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 den Datenmitwirkenden (Primus Bank in diesem Codelab) autorisiert und der Arbeitslastbetreiber (in diesem Fall 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 Skripts 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 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 basierend auf Ihrer Projekt-ID für Ressourcennamen festzulegen.

source config_env.sh

Installieren Sie cosign gemäß der Anleitung.

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 Primus Bank einzurichten. Im Rahmen dieser Schritte werden die unten aufgeführten 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) zum Validieren von Ansprüchen basierend auf Attributbedingungen, die unter dem zugehörigen Anbieter konfiguriert sind.
Dienstkonto ($PRIMUS_SERVICEACCOUNT), das dem oben genannten Workload Identity-Pool ($PRIMUS_WORKLOAD_IDENTITY_POOL) zugeordnet ist, mit dem folgenden 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 unten genannten Ressourcen erstellt:

Cloud Storage-Bucket ($SECUNDUS_RESULT_STORAGE_BUCKET) zum Speichern des Ergebnisses der Ausführung der Arbeitslast durch Secundus Bank.

./setup_secundus_bank_resources.sh

3. Arbeitslast erstellen und signieren

Dienstkonto für Arbeitslast erstellen

Als Nächstes erstellen Sie ein Dienstkonto für die Arbeitslast mit den erforderlichen Rollen und Berechtigungen. Führen Sie das folgende Script aus, um ein Dienstkonto für Arbeitslasten im Secundus-Bankprojekt zu erstellen. Dieses Dienstkonto wird von der VM verwendet, auf der der Arbeitslast ausgeführt wird.

Dieses Dienstkonto für Arbeitslasten ($WORKLOAD_SERVICEACCOUNT) hat die folgenden Rollen:
confidentialcomputing.workloadUser, um ein Attestierungstoken zu erhalten
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 den Kundendaten der Primus Bank) anhand eines angegebenen geografischen Standorts im Argument zählt. Führen Sie das folgende Skript aus, um eine Arbeitslast zu erstellen, in der die folgenden Schritte ausgeführt werden:

Erstelle eine Artifact Registry-Instanz($SECUNDUS_ARTIFACT_REGISTRY), die der Secundus Bank gehört.
Aktualisieren Sie den Arbeitslastcode mit den erforderlichen Ressourcennamen. Hier finden Sie den Arbeitslastcode, der für dieses Codelab verwendet wird.
Go-Binärdatei erstellen und Dockerfile zum Erstellen eines Docker-Images des Arbeitslastcodes 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 zum Signieren des Arbeitslast-Images. 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 Registries 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 einen Schlüsselbund und einen Schlüssel in KMS 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 ist ein vollständiger Image-Name wie $LOCATION/$PROJECT/$REPOSITORY/$IMAGE_NAME erforderlich. Sie können ein beliebiges Container-Image in das Repository für die Signaturspeicherung 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 $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 benötigen wir nur Cosign, um mit einem Schlüsselpaar zu signieren. Die schlüssellose Signierung von Cosign wird für diese Funktion für signierte Container-Images nicht unterstützt.

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

Mit einem lokalen Schlüsselpaar signieren, 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 Mit selbst verwalteten Schlüsseln signieren. Hier haben wir beide Möglichkeiten (lokal und mit dem KMS-Anbieter) zum Generieren des Schlüsselpaars und zum Signieren der Arbeitslast angegeben. 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

Signieren Sie die Arbeitslast mit Cosign. Führen Sie eine nicht aufgefüllte Base64-Codierung für den öffentlichen Schlüssel 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 mit dem exportierten öffentlichen Schlüssel und den angehängten 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 auf einen von einem KMS-Anbieter verwalteten Schlüssel verweisen, halten Sie sich bitte an das spezifische URI-Format unter Sigstore KMS-Unterstützung. Verwenden Sie beim Verweis auf einen von Cosign generierten Schlüssel stattdessen cosign.key.
$IMAGE_REFERENCE [ERFORDERLICH] gibt an, welches Container-Image signiert werden soll. Das Format von IMAGE_REFERENCE kann anhand des Tags oder des Image-Digests ermittelt 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 Annotationen an, die an die Signaturnutzlast angehängt werden. Für signierte Confidential Space-Container-Images müssen öffentliche Schlüssel und Signaturalgorithmen an die Signaturnutzlast angehängt werden.

dev.cosignproject.cosign/sigalg NUR akzeptiert drei Werte:
RSASSA_PSS_SHA256: RSASSA-Algorithmus mit PSS-Padding und einem SHA256-Digest.
RSASSA_PKCS1V15_SHA256: RSASSA-Algorithmus mit PKCS#1 v1.5-Padding und 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

Cosign lädt Signaturen automatisch in das angegebene COSIGN_REPOSITORY. hoch.

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 sind Attributbedingungen konfiguriert, wie unten dargestellt. Eine der Bedingungen ist, den Fingerabdruck der Arbeitslast-Image-Signatur mit dem Fingerabdruck des öffentlichen Signaturschlüssels abzugleichen. Wenn Secundus Bank mit dieser Attributbedingung ein neues Arbeitslast-Image veröffentlicht, prüft 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 über das Metadaten-Flag übergeben. Argumente für den Arbeitslastcontainer werden über den Teil „tee-cmd“ des Flags übergeben. Die Arbeitslast ist so codiert, dass ihr 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 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 aufgeführt sind.

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:

Eingabe-Speicher-Bucket der Primus Bank ($PRIMUS_INPUT_STORAGE_BUCKET).
Primus-Bankdienstkonto ($PRIMUS_SERVICEACCOUNT).
Primus Bank-Artifact Registry, in der Bildsignaturen gespeichert werden ($PRIMUS_COSIGN_REPOSITORY).
Workload Identity-Pool der Primus Bank ($PRIMUS_WORKLOAD_IDENTITY_POOL).
Arbeitslast-Dienstkonto der Secundus Bank ($WORKLOAD_SERVICEACCOUNT).
Compute-Instanz für Arbeitslast.
Ergebnis-Storage-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 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 die Funktion für signierte Container-Images nutzen können, um die Benutzerfreundlichkeit von Confidential Space zu verbessern.

Nächste Schritte

Hier finden Sie einige ähnliche Codelabs: