Erste Schritte mit der Google Cloud CLI (GKE)

In diesem Leitfaden wird beschrieben, wie Sie eine Richtlinie für Binärautorisierungen konfigurieren und testen, die Attestierungen erfordert. Mit diesem Richtlinientyp wird die Container-basierte Softwarelieferkette gesichert. Dazu wird geprüft, ob ein Container-Image eine signierte Attestierung hat, bevor die Bereitstellung des Images zugelassen wird.

Zum Zeitpunkt des Deployments verwendet die Binärautorisierung Attestierer, um digitale Signaturen in Attestierungen zu prüfen. Die Attestierungen werden von den Signern erstellt, normalerweise im Rahmen einer CI-Pipeline (Continuous Integration).

In dieser Anleitung befinden sich der GKE-Cluster, die Attestierungen und die Attestierer alle innerhalb desselben Projekts. Eine Konfiguration mit einem einzelnen Projekt eignet sich vor allem für Tests oder Experimente mit dem Dienst. Ein Praxisbeispiel finden Sie unter Konfiguration mit mehreren Projekten.

Nachstehend werden die Aufgaben beschrieben, die Sie über die Befehlszeile ausführen. Wie Sie diese Schritte mit der Google Cloud Console ausführen, erfahren Sie unter Erste Schritte mit der Google Cloud Console.

Ziele

In dieser Anleitung erfahren Sie mehr über die folgenden Themen:

Google Kubernetes Engine-Cluster mit aktivierter Binärautorisierung erstellen
Attestierer erstellen, mit dem der Binärautorisierungserzwinger die Signatur einer Attestierung prüft
Richtlinie konfigurieren, die eine Attestierung erfordert
Kryptografisches Schlüsselpaar erstellen, um Attestierungen zu signieren und später zu prüfen
Container-Image-Digest signieren und eine Signatur erstellen
Attestierung mit der Signatur erstellen
Container-Image in GKE bereitstellen, um die Richtlinie zu testen

Kosten

In diesem Dokument verwenden Sie die folgenden kostenpflichtigen Komponenten von Google Cloud:

Artifact Registry oder Container Registry
Binärautorisierung
GKE
Optional: Cloud Key Management Service

Mit dem Preisrechner können Sie eine Kostenschätzung für Ihre voraussichtliche Nutzung vornehmen. Neuen Google Cloud-Nutzern steht möglicherweise eine kostenlose Testversion zur Verfügung.

Hinweis

Melden Sie sich bei Ihrem Google Cloud-Konto an. Wenn Sie mit Google Cloud noch nicht vertraut sind, erstellen Sie ein Konto, um die Leistungsfähigkeit unserer Produkte in der Praxis sehen und bewerten zu können. Neukunden erhalten außerdem ein Guthaben von 300 $, um Arbeitslasten auszuführen, zu testen und bereitzustellen.

Wählen Sie in der Google Cloud Console auf der Seite der Projektauswahl ein Google Cloud-Projekt aus oder erstellen Sie eines.

Zur Projektauswahl

Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein.

Installieren Sie die Google Cloud CLI.

Führen Sie folgenden Befehl aus, um die gcloud CLI zu initialisieren:

gcloud init

Wählen Sie in der Google Cloud Console auf der Seite der Projektauswahl ein Google Cloud-Projekt aus oder erstellen Sie eines.

Zur Projektauswahl

Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein.

Installieren Sie die Google Cloud CLI.

Führen Sie folgenden Befehl aus, um die gcloud CLI zu initialisieren:

gcloud init

Installieren Sie kubectl für die Interaktion mit GKE.

Binärautorisierung aktivieren

Standardprojekt festlegen

Im ersten Schritt legen Sie das Google Cloud-Standardprojekt fest, das vom gcloud-Befehl verwendet werden soll.

PROJECT_ID=PROJECT_ID
gcloud config set project ${PROJECT_ID}

Dabei ist PROJECT_ID der Name Ihres Projekts.

Erforderliche APIs aktivieren

APIs aktivieren für:

Container Registry

gcloud --project=${PROJECT_ID} \
    services enable\
    container.googleapis.com\
    containerregistry.googleapis.com\
    binaryauthorization.googleapis.com

Artifact Registry

gcloud --project=${PROJECT_ID} \
    services enable\
    container.googleapis.com\
    artifactregistry.googleapis.com\
    binaryauthorization.googleapis.com

Cluster mit aktivierter Binärautorisierung erstellen

Cluster erstellen

GKE-Cluster mit aktivierter Binärautorisierung erstellen. Dies ist der Cluster, in dem die bereitgestellten Container-Images ausgeführt werden sollen. Wenn Sie den Cluster erstellen, übergeben Sie das Flag --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE an den Befehl gcloud container clusters create.

So erstellen Sie den Cluster:

gcloud container clusters create \
    --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE \
    --zone us-central1-a \
    test-cluster

Hier erstellen Sie einen Cluster mit dem Namen test-cluster in der GKE-Zone us-central1-a.

`kubectl` konfigurieren

Sie müssen für Ihre kubectl-Installation auch die lokale Datei kubeconfig aktualisieren. Dadurch werden die Anmeldedaten und Endpunktinformationen bereitgestellt, die für den Zugriff auf den Cluster in GKE erforderlich sind.

So aktualisieren Sie die lokale Datei kubeconfig:

gcloud container clusters get-credentials \
    --zone us-central1-a \
    test-cluster

Standardrichtlinie ansehen

Eine Richtlinie im Rahmen der Binärautorisierung ist eine Reihe von Regeln für das Deployment von Container-Images. Sie können pro Projekt jeweils nur eine Richtlinie festlegen. Standardmäßig ist die Richtlinie so konfiguriert, dass alle Container-Images bereitgestellt werden können.

Mit der Binärautorisierung können Sie eine Richtliniendatei im YAML-Format exportieren und importieren. Dieses Format spiegelt die Struktur einer Richtlinie wider, wie sie vom Dienst gespeichert wird. Wenn Sie eine Richtlinie mit gcloud-Befehlen konfigurieren, bearbeiten Sie diese Datei.

Um die Standardrichtlinie aufzurufen, exportieren Sie die YAML-Richtliniendatei:

gcloud container binauthz policy export

Die Datei hat standardmäßig folgenden Inhalt:

admissionWhitelistPatterns:
- namePattern: gcr.io/google_containers/*
- namePattern: gcr.io/google-containers/*
- namePattern: k8s.gcr.io/**
- namePattern: gke.gcr.io/**
- namePattern: gcr.io/stackdriver-agents/*
globalPolicyEvaluationMode: ENABLE
defaultAdmissionRule:
  evaluationMode: ALWAYS_ALLOW
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
name: projects/${PROJECT_ID}/policy

Die Standardliste enthält die Open-Source-Community-Registry k8s.gcr.io, die durch registry.k8s.io ersetzt wird und in der Liste für Abwärtskompatibilität gespeichert ist. Die Ersatz-Registry registry.k8s.io ist nicht in der Standardliste enthalten. Wenn Sie von k8s.gcr.io migrieren, wechseln Sie zu der Registry, über die Sie die Kontrolle haben, oder fügen Sie die Ersatz-Registry registry.k8s.io zu dieser Liste hinzu.

Hier wird die Standardregel im Knoten defaultAdmissionRule definiert. evaluationMode gibt an, dass die Richtlinie alle Image-Deployments zulässt. In dieser Anleitung aktualisieren Sie die Standardregel so, dass Attestierungen erforderlich sind.

Weitere Informationen zur Struktur einer Richtlinie finden Sie in der Referenz zu YAML-Richtlinien.

Attestierer erstellen

Ein Attestierer ist die Verifizierungsstelle, die der Binärautorisierungserzwinger zum Zeitpunkt des Deployments verwendet. Er entscheidet, ob GKE das entsprechende signierte Container-Image bereitstellen darf. Der Attestierer enthält den öffentlichen Schlüssel und wird in der Regel von Personal Ihrer Organisation verwaltet, das für die Sicherheit der Softwarelieferkette verantwortlich ist.

So erstellen Sie einen Attestierer:

Erstellen Sie in Artefaktanalyse einen Hinweis, um vertrauenswürdige Metadaten zu speichern, die während des Autorisierungsvorgangs verwendet werden.
Erstellen Sie den Attestierer selbst in der Binärautorisierung und verknüpfen Sie den zuvor erstellten Hinweis.

In dieser Anleitung haben Sie einen Attestierer namens test-attestor und einen Container Analysis-Hinweis mit dem Namen test-attestor-note. In der Praxis können Sie eine beliebige Anzahl von Attestierern haben. Dabei repräsentiert jeder Attestierer eine Partei, die am Autorisierungsprozess für ein Container-Image beteiligt ist.

Artefaktanalyse-Hinweis erstellen

Legen Sie Variablen fest, in denen der Name des Attestierers und der Artefaktanalyse-Hinweis gespeichert sind:
```
ATTESTOR_NAME=test-attestor
NOTE_ID=test-attestor-note
```
Ersetzen Sie:
- test-attestor: der Name des Attestierers Ihrer Wahl
- attestor-note: der Hinweisname des Attestierers Ihrer Wahl

Erstellen Sie in /tmp/note_payload.json eine JSON-Datei, die den Container Analysis-Hinweis beschreibt:

cat > /tmp/note_payload.json << EOM
{
  "name": "projects/${PROJECT_ID}/notes/${NOTE_ID}",
  "attestation": {
    "hint": {
      "human_readable_name": "Attestor Note"
    }
  }
}
EOM

Erstellen Sie den Hinweis, indem Sie eine HTTP-Anfrage an die Artifact Analysis REST API senden:

curl -X POST \
    -H "Content-Type: application/json" \
    -H "Authorization: Bearer $(gcloud auth print-access-token)"  \
    --data-binary @/tmp/note_payload.json  \
    "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/?noteId=${NOTE_ID}"

Prüfen Sie, ob der Hinweis erstellt wurde:

curl \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
"https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/${NOTE_ID}"

Attestierer erstellen

Jetzt können Sie den Attestierer erstellen:

Erstellen Sie den Attestierer in der Binärautorisierung:

gcloud container binauthz attestors create ${ATTESTOR_NAME} \
--attestation-authority-note=${NOTE_ID} \
--attestation-authority-note-project=${PROJECT_ID}

Prüfen Sie, ob der Attestierer erstellt wurde:
```
gcloud container binauthz attestors list
```

Der von Ihnen erstellte Attestierer kann jetzt noch nicht verwendet werden. Es fehlt noch ein verknüpftes PKIX-Schlüsselpaar, das Sie unten erstellen.

Für eine Konfiguration mit mehreren Projekten müssen Sie Berechtigungen für den Container Analysis-Hinweis festlegen, wie unter Mehrere Projekte einrichten beschrieben. Dies ist in einem Szenario mit einem einzelnen Projekt nicht erforderlich, da das Projekt die erforderliche Berechtigung roles/containeranalysis.notes.occurrences.viewer standardmäßig hat.

Schlüsselpaar generieren

Die Binärautorisierung verwendet kryptografische Schlüssel, um die Identität von Signern sicher zu verifizieren. Dies gewährleistet, dass nur autorisierte Container-Images bereitgestellt werden können. Das Schlüsselpaar besteht aus einem privaten und einem öffentlichen Schlüssel. Der Signer signiert den Container-Image-Digest mit dem privaten Schlüssel und erzeugt damit eine Signatur, die dann in einer Attestierung gespeichert wird. Der öffentliche Schlüssel wird im Attestierer gespeichert. Beim Deployment prüft der Binärautorisierungserzwinger mit dem öffentlichen Schlüssel des Attestierers die Signatur in der Attestierung, bevor der Container bereitgestellt werden kann.

In dieser Anleitung verwenden Sie für kryptografische Schlüssel das Format Public-Key-Infrastructure (X.509). Ferner wird in dieser Anleitung der empfohlene Elliptic Curve Digital Signing Algorithm (ECDSA) verwendet, um ein PKIX-Schlüsselpaar zu generieren. Sie können zum Signieren auch RSA- oder PGP-Schlüssel verwenden.

Weitere Informationen zu Signaturalgorithmen finden Sie unter Schlüsselzwecke und Algorithmen.

Die vom Cloud Key Management Service (Cloud KMS) generierten und gespeicherten Schlüssel sind PKIX-konform. Weitere Informationen zur Verwendung von PKIX-Schlüsseln und Cloud KMS finden Sie unter Attestierer über die gcloud CLI erstellen.

PKIX (Cloud KMS)

So erstellen Sie das Schlüsselpaar in Cloud KMS:

Richten Sie Umgebungsvariablen ein, die zum Erstellen des Schlüsselpaars erforderlich sind.

KMS_KEY_PROJECT_ID=${PROJECT_ID}
KMS_KEYRING_NAME=my-binauthz-keyring
KMS_KEY_NAME=my-binauthz-kms-key-name
KMS_KEY_LOCATION=global
KMS_KEY_PURPOSE=asymmetric-signing
KMS_KEY_ALGORITHM=ec-sign-p256-sha256
KMS_PROTECTION_LEVEL=software
KMS_KEY_VERSION=1

Führen Sie den folgenden Befehl aus, um das Schlüsselbund zu erstellen:

gcloud kms keyrings create ${KMS_KEYRING_NAME} \
  --location ${KMS_KEY_LOCATION}

Führen Sie den folgenden Befehl aus, um den Schlüssel zu erstellen:

gcloud kms keys create ${KMS_KEY_NAME} \
  --location ${KMS_KEY_LOCATION} \
  --keyring ${KMS_KEYRING_NAME}  \
  --purpose ${KMS_KEY_PURPOSE} \
  --default-algorithm ${KMS_KEY_ALGORITHM} \
  --protection-level ${KMS_PROTECTION_LEVEL}

Führen Sie den folgenden Befehl aus, um den öffentlichen Schlüssel zum Attestierer hinzuzufügen:

gcloud --project="${PROJECT_ID}" \
    container binauthz attestors public-keys add \
    --attestor="${ATTESTOR_NAME}" \
    --keyversion-project="${KMS_KEY_PROJECT_ID}" \
    --keyversion-location="${KMS_KEY_LOCATION}" \
    --keyversion-keyring="${KMS_KEYRING_NAME}" \
    --keyversion-key="${KMS_KEY_NAME}" \
    --keyversion="${KMS_KEY_VERSION}"

Rufen Sie die ID des öffentlichen Schlüssels vom Attestierer so ab:

Sie können die ID Ihres öffentlichen Schlüssels jederzeit mit dem folgenden Befehl abrufen: gcloud container binauthz attestors describe <var>ATTESTOR_NAME</var>.

Um die ID des öffentlichen Schlüssels in einer Umgebungsvariablen zu speichern, geben Sie den folgenden Befehl ein:
```
PUBLIC_KEY_ID=$(gcloud container binauthz attestors describe ${ATTESTOR_NAME} \
--format='value(userOwnedGrafeasNote.publicKeys[0].id)' --project ${PROJECT_ID})
```

PKIX (lokaler Schlüssel)

So generieren Sie ein PKIX-Schlüsselpaar:

Erstellen Sie den privaten Schlüssel:

PRIVATE_KEY_FILE="/tmp/ec_private.pem"
openssl ecparam -genkey -name prime256v1 -noout -out ${PRIVATE_KEY_FILE}

Extrahieren Sie den öffentlichen Schlüssel aus dem privaten Schlüssel:

PUBLIC_KEY_FILE="/tmp/ec_public.pem"
openssl ec -in ${PRIVATE_KEY_FILE} -pubout -out ${PUBLIC_KEY_FILE}

Fügen Sie dem Attestierer den öffentlichen Schlüssel hinzu.

Fügen Sie nun den öffentlichen Schlüssel hinzu, den Sie in den Attestierer exportiert haben, damit er von der Binärautorisierung für die Identitätsprüfung verwendet werden kann:
```
gcloud --project="${PROJECT_ID}" \
    beta container binauthz attestors public-keys add \
    --attestor="${ATTESTOR_NAME}" \
    --pkix-public-key-file=${PUBLIC_KEY_FILE} \
    --pkix-public-key-algorithm=ecdsa-p256-sha256
```
Hinweis: Mit diesem Befehl wird die PUBLIC_KEY_ID ausgegeben, die Sie beim Erstellen einer Attestierung verwenden. Sie befindet sich im Feld id der Ausgabe und sieht etwa so aus: ni:///sha-256;ybf_gINTzsBKLCaRIeQnExNhKFkGONXXXlr63QeZY-Q.
Speichern Sie die ID des öffentlichen Schlüssels.

Zum Speichern der öffentlichen Schlüssel-ID können Sie diese aus der Ausgabe von public-keys add oben kopieren. Verwenden Sie diesen Befehl, um die ID des öffentlichen Schlüssels Ihres Attestierers aufzurufen, nachdem Sie sie dem Attestierer hinzugefügt haben: gcloud container binauthz attestors describe ${ATTESTOR_NAME}
```
PUBLIC_KEY_ID=$(gcloud container binauthz attestors describe ${ATTESTOR_NAME} \
  --format='value(userOwnedGrafeasNote.publicKeys[0].id)')
```

Richtlinie konfigurieren

Jetzt können Sie Ihre Richtlinie konfigurieren: In diesem Schritt exportieren Sie die YAML-Richtliniendatei in Ihr lokales System. Dort ändern Sie die Standardregel so, dass sie eine Attestierung durch den Attestierer erfordert, den Sie oben definiert haben.

So konfigurieren Sie die Richtlinie:

Erstellen Sie eine neue Richtliniendatei, die von Google verwaltete Systemimages zulässt, evaluationMode auf REQUIRE_ATTESTATION setzt und einen Knoten mit dem Namen requireAttestationsBy hinzufügt, der auf den von Ihnen erstellten Attestierer verweist:

cat > /tmp/policy.yaml << EOM
    globalPolicyEvaluationMode: ENABLE
    defaultAdmissionRule:
      evaluationMode: REQUIRE_ATTESTATION
      enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
      requireAttestationsBy:
        - projects/${PROJECT_ID}/attestors/${ATTESTOR_NAME}
    name: projects/${PROJECT_ID}/policy
EOM

Importieren Sie die YAML-Richtliniendatei in die Binärautorisierung:
```
gcloud container binauthz policy import /tmp/policy.yaml
```

Weitere Informationen zum Konfigurieren einer Richtlinie finden Sie unter Richtlinie über die gcloud CLI konfigurieren.

Richtlinie testen

Stellen Sie ein Beispiel-Container-Image für den Cluster bereit, um die Richtlinie zu testen. Das Deployment wird von der Richtlinie blockiert, da die erforderliche Attestierung nicht erfolgt ist.

Für diese Anleitung können Sie Beispiel-Images aus Container Registry und Artifact Registry verwenden. Das Image aus Container Registry befindet sich unter dem Pfad gcr.io/google-samples/hello-app:1.0. Das Image aus Artifact Registry befindet sich unter dem Pfad us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0. Beide Pfade enthalten ein von Google erstelltes öffentliches Image, das die Beispielanwendung "Hello, World!" enthält.

Versuchen Sie zuerst, das Image bereitzustellen:

kubectl run hello-server --image gcr.io/google-samples/hello-app:1.0 --port 8080

Prüfen Sie nun, ob das Deployment durch die Binärautorisierung blockiert wurde:

kubectl get pods

Der Befehl gibt die folgende Meldung aus, dass das Image nicht bereitgestellt wurde:

No resources found.

Sie können weitere Details zum Deployment abrufen:

kubectl get event --template \
'{{range.items}}{{"\033[0;36m"}}{{.reason}}:{{"\033[0m"}}\{{.message}}{{"\n"}}{{end}}'

Die Antwort sieht in etwa so aus:

FailedCreate: Error creating: pods POD_NAME is forbidden: admission webhook "imagepolicywebhook.image-policy.k8s.io" denied the request: Image IMAGE_NAME denied by Binary Authorization default admission rule. Image IMAGE_NAME denied by attestor ATTESTOR_NAME: No attestations found

In dieser Ausgabe gilt:

POD_NAME: der Name des Pods
IMAGE_NAME: der Name des Images
ATTESTOR_NAME: der Name des Attestierers

Das Deployment muss für den nächsten Schritt gelöscht werden.

kubectl delete deployment hello-server

Attestierung erstellen

Eine Attestierung ist ein digitales Dokument, das von einem Signer erstellt wird und bestätigt, dass GKE das zugehörige Container-Image bereitstellen darf. Das Erstellen einer Attestierung wird manchmal als "Signieren eines Images" bezeichnet. Ein Signer kann eine Person sein, ist aber meistens ein automatisierter Prozess, der beim Erstellen eines Container-Images ausgeführt wird. Die Signatur wird mit dem privaten Schlüssel aus einem Schlüsselpaar erstellt. Beim Deployment prüft der Binärautorisierungserzwinger mit dem öffentlichen Schlüssel des Attestierers die Signatur in der Attestierung.

In dieser Anleitung wird in der Attestierung einfach angegeben, dass Sie das Image für das Deployment autorisieren.

So erstellen Sie eine Attestierung:

Legen Sie Variablen fest, die den Registry-Pfad und den Digest des Images speichern:

Container Registry

IMAGE_PATH="gcr.io/google-samples/hello-app"
IMAGE_DIGEST="sha256:c62ead5b8c15c231f9e786250b07909daf6c266d0fcddd93fea882eb722c3be4"
IMAGE_TO_ATTEST=${IMAGE_PATH}@${IMAGE_DIGEST}

Artifact Registry

IMAGE_PATH="us-docker.pkg.dev/google-samples/containers/gke/hello-app"
IMAGE_DIGEST="sha256:37e5287945774f27b418ce567cd77f4bbc9ef44a1bcd1a2312369f31f9cce567"
IMAGE_TO_ATTEST=${IMAGE_PATH}@${IMAGE_DIGEST}

So erstellen Sie die Attestierung:
PKIX Cloud KMS
Führen Sie folgenden Befehl aus, um die Attestierung mit dem Cloud KMS-Schlüssel zu erstellen:
```
gcloud beta container binauthz attestations sign-and-create \
    --project="${PROJECT_ID}" \
    --artifact-url="${IMAGE_TO_ATTEST}" \
    --attestor="${ATTESTOR_NAME}" \
    --attestor-project="${PROJECT_ID}" \
    --keyversion-project="${KMS_KEY_PROJECT_ID}" \
    --keyversion-location="${KMS_KEY_LOCATION}" \
    --keyversion-keyring="${KMS_KEYRING_NAME}" \
    --keyversion-key="${KMS_KEY_NAME}" \
    --keyversion="${KMS_KEY_VERSION}"
```
PKIX (lokaler Schlüssel)
So erstellen Sie die Attestierung mit dem lokalen Schlüssel:
1. Erstellen Sie die Attestierungsnutzlast:
  
  Hinweis: Im folgenden Befehl ist zwar ein ${IMAGE_PATH} erforderlich, um die Signaturnutzlast für die Attestierung zu erstellen, aber zum Zeitpunkt des Deployments wird nur der ${IMAGE_DIGEST} verwendet. Dies bedeutet, dass Sie mit derselben Attestierung ein identisches Container-Image von mehreren Standorten aus bereitstellen können.
```
gcloud container binauthz create-signature-payload \
--artifact-url=${IMAGE_TO_ATTEST} > /tmp/generated_payload.json
```
  Die JSON-Nutzlastdatei hat folgenden Inhalt:
```
{
"critical": {
  "identity": {
    "docker-reference": "gcr.io/google-samples/hello-app"
  },
  "image": {
    "docker-manifest-digest": "sha256:c62ead5b8c15c231f9e786250b07909daf6c266d0fcddd93fea
882eb722c3be4"
  },
  "type": "Google cloud binauthz container signature"
}
}
```
2. Führen Sie den folgenden Befehl aus, um die Nutzlast mit dem privaten PKIX-Schlüssel zu signieren und eine Signaturdatei zu generieren:
```
openssl dgst -sha256 -sign ${PRIVATE_KEY_FILE} /tmp/generated_payload.json > /tmp/ec_signature
```
  Die Signaturdatei ist die signierte Version der JSON-Nutzlastdatei, die Sie zuvor in dieser Anleitung erstellt haben.
3. Erstellen und validieren Sie die Attestierung:
```
gcloud container binauthz attestations create \
  --project="${PROJECT_ID}" \
  --artifact-url="${IMAGE_TO_ATTEST}" \
  --attestor="projects/${PROJECT_ID}/attestors/${ATTESTOR_NAME}" \
  --signature-file=/tmp/ec_signature \
  --public-key-id="${PUBLIC_KEY_ID}" \
  --validate
```
  Ersetzen Sie PUBLIC_KEY_ID durch die ID des öffentlichen Schlüssels, die Sie oben im Abschnitt PKIX-Schlüsselpaar generieren ermittelt haben.
  
  Das Flag validate prüft, ob die Attestierung von dem Attestierer geprüft werden kann, den Sie in Ihrer Richtlinie konfiguriert haben.

Prüfen Sie, ob die Attestierung erstellt wurde:

gcloud container binauthz attestations list \
    --attestor=$ATTESTOR_NAME --attestor-project=$PROJECT_ID

Weitere Informationen zum Erstellen von Attestierungen finden Sie unter Attestierungen erstellen.

Richtlinie noch einmal testen

Testen Sie die Richtlinie noch einmal. Dazu stellen Sie ein Beispiel-Container-Image für den Cluster bereit. Dieses Mal müssen Sie das Image mit dem Digest anstelle eines Tags wie 1.0 oder latest bereitstellen, da die Binärautorisierung sowohl den Image-Pfad als auch den Digest zur Suche nach Attestierungen verwendet. Das Deployment des Images wird hier von der Binärautorisierung zugelassen, da die erforderliche Attestierung erstellt wurde.

So stellen Sie das Image bereit:

kubectl run hello-server --image ${IMAGE_TO_ATTEST} --port 8080

So prüfen Sie, ob das Image bereitgestellt wurde:

kubectl get pods

Der Befehl gibt eine Nachricht ähnlich der folgenden aus, die zeigt, dass das Deployment erfolgreich war:

NAME                            READY     STATUS    RESTARTS   AGE
hello-server-579859fb5b-h2k8s   1/1       Running   0          1m

Bereinigen

Damit Ihrem Google Cloud-Konto die in dieser Anleitung verwendeten Ressourcen nicht in Rechnung gestellt werden, löschen Sie entweder das Projekt, das die Ressourcen enthält, oder Sie behalten das Projekt und löschen die einzelnen Ressourcen.

Löschen Sie den Cluster, den Sie in GKE erstellt haben:

gcloud container clusters delete \
    --zone=us-central1-a \
    test-cluster

Nächste Schritte

Weitere Informationen zur Binärautorisierung
Schlüsselkonzepte der Binärautorisierung kennenlernen
Verwenden Sie den Attestierer built-by-cloud-build, um nur von Cloud Build erstellte Images bereitzustellen (Vorschau).
Probelaufmodus aktivieren, um die Erzwingung zu deaktivieren
Break-Glass verwenden, um die Erzwingung zu umgehen

Erste Schritte mit der Google Cloud CLI (GKE)

Ziele

Kosten

Hinweis

Binärautorisierung aktivieren

Standardprojekt festlegen

Erforderliche APIs aktivieren

Container Registry

Artifact Registry

Cluster mit aktivierter Binärautorisierung erstellen

Cluster erstellen

kubectl konfigurieren

Standardrichtlinie ansehen

Attestierer erstellen

Artefaktanalyse-Hinweis erstellen

Attestierer erstellen

Schlüsselpaar generieren

PKIX (Cloud KMS)

PKIX (lokaler Schlüssel)

Richtlinie konfigurieren

Richtlinie testen

Attestierung erstellen

Container Registry

Artifact Registry

PKIX Cloud KMS

PKIX (lokaler Schlüssel)

Richtlinie noch einmal testen

Bereinigen

Nächste Schritte

`kubectl` konfigurieren