In diesem Leitfaden wird beschrieben, wie Sie eine Richtlinie für Binärautorisierungen konfigurieren und testen, die Attestierungen erfordert. Diese Art von Richtlinie schützt Ihre containerbasierte Softwarelieferkette, weil darin definiert wird, wer Container-Images in Google Kubernetes Engine (GKE) bereitstellen kann und welche Container-Images in GKE bereitgestellt werden dürfen.
Zum Zeitpunkt des Deployments verwendet die Binärautorisierung Attestierer, um digitale Signaturen in Attestierungen zu prüfen. Die Attestierungen wurden von den Signern im Rahmen des Build-Prozesses erstellt.
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 verschiedene Aufgaben beschrieben, von denen einige in der Google Cloud Console und andere mit gcloud
-Befehlen ausgeführt werden. Informationen zum Ausführen dieser Schritte mit gcloud
finden Sie unter Erste Schritte mit der Google Cloud CLI.
Ziele
In dieser Anleitung erfahren Sie mehr über die folgenden Themen:
- GKE-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
- Binary Authorization
- GKE
- Container Registry
- Optional: Cloud Key Management Service
Mit dem Preisrechner können Sie eine Kostenschätzung für Ihre voraussichtliche Nutzung vornehmen.
Hinweise
- Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Make sure that billing is enabled for your Google Cloud project.
-
Enable the Container Registry, Artifact Analysis and Binary Authorization APIs.
- Install the Google Cloud CLI.
-
To initialize the gcloud CLI, run the following command:
gcloud init
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Make sure that billing is enabled for your Google Cloud project.
-
Enable the Container Registry, Artifact Analysis and Binary Authorization APIs.
- Install the Google Cloud CLI.
-
To initialize the gcloud CLI, run the following command:
gcloud init
- Installieren Sie
kubectl
:
Standardprojekt festlegen
Speichern Sie Ihre Google Cloud-Projekt-ID so in einer Umgebungsvariablen, um die Befehlsausführung zu erleichtern:
PROJECT_ID=PROJECT_ID
Dabei ist PROJECT_ID der Name Ihres Projekts.
Wenn das Standardprojekt nicht ausgewählt ist, legen Sie es jetzt fest:
gcloud config set project ${PROJECT_ID}
Cluster mit aktivierter Binärautorisierung erstellen
Cluster erstellen
Nun können Sie einen GKE-Cluster mit aktivierter Binärautorisierung erstellen. Hier erstellen Sie einen Cluster mit dem Namen test-cluster
in der GKE-Zone us-central1-a
.
So erstellen Sie den Cluster:
Rufen Sie in der Google Cloud Console das GKE-Menü auf.
Klicken Sie auf Cluster erstellen.
Geben Sie in das Feld Name
test-cluster
ein.Wählen Sie unter Standorttyp die Option Zonal aus.
Wählen Sie aus der Drop-down-Liste Zone
us-central1-a
aus.Klicken Sie auf Verfügbarkeit, Netzwerk, Sicherheit und weitere Features.
Wählen Sie im Abschnitt Sicherheit die Option Binärautorisierung aktivieren aus.
Wählen Sie Nur erzwingen aus.
Klicken Sie auf Erstellen.
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.
So rufen Sie die Standardrichtlinie auf:
Rufen Sie in der Google Cloud Console die Seite "Binärautorisierung" auf.
Klicken Sie auf Richtlinie bearbeiten.
Unter Projektstandardregel wird die Option Alle Images zulassen angezeigt.
Klicken Sie auf Richtlinie speichern.
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 normalerweise von Personen verwaltet, die für die Sicherheit der Softwarelieferkette verantwortlich sind.
So erstellen Sie einen Attestierer:
- Erstellen Sie den Attestierer selbst in der Binärautorisierung
- Lassen Sie in Artefaktanalyse einen verknüpften Attestierer-Hinweis automatisch erstellen, um vertrauenswürdige Attestierungsmetadaten zu speichern, die im Autorisierungsprozess verwendet werden
Für diese Anleitung haben Sie einen Attestierer namens test-attestor
. In der Praxis können Sie eine beliebige Anzahl von Attestierern haben. Dabei repräsentiert jeder Attestierer eine Partei, die am Autorisierungsprozess für das Image beteiligt ist.
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 Signieralgorithmen 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 Befehlszeile erstellen.
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}
Attestierer erstellen
Jetzt können Sie in der Binärautorisierung den Attestierer selbst erstellen und den von Ihnen erstellten öffentlichen Schlüssel verknüpfen.
So erstellen Sie den Attestierer:
Kehren Sie zur Seite der Binärautorisierung in der Google Cloud Console zurück.
Klicken Sie im Tab Attestierer auf Erstellen.
Füllen Sie die Felder so aus:
Geben Sie in das Feld Name des Attestierers
test-attestor
ein.Prüfen Sie, ob das Kästchen Artefaktanalyse-Hinweis automatisch erstellen angeklickt ist.
Klicken Sie auf Öffentlichen PKIX-Schlüssel hinzufügen.
Öffnen Sie
/tmp/ec_public.pem
in einem Texteditor. Dies ist die öffentliche Schlüsseldatei, die Sie im vorherigen Schritt erstellt haben. Kopieren Sie den Inhalt der Datei in das Textfeld Material von öffentlichem Schlüssel.Klicken Sie im Drop-down-Menü Signaturalgorithmus auf
Elliptic Curve P-256 - SHA256 Digest
.Klicken Sie auf Fertig.
Klicken Sie auf Erstellen, um den Attestierer zu erstellen.
Speichern Sie die ID des öffentlichen Schlüssels.
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}
. Führen Sie den folgenden Befehl aus, um eine Umgebungsvariable zum Speichern der öffentlichen Schlüssel-ID zu erstellen:ATTESTOR_NAME=test-attestor 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:
Kehren Sie in der Google Cloud Console zur Seite der Binärautorisierung zurück.
Im Tab Richtlinie klicken Sie auf Richtlinie bearbeiten.
Wählen Sie Nur Images zulassen, die von allen folgenden Attestierern genehmigt wurden aus.
Klicken Sie auf Attestierer hinzufügen.
Klicken Sie auf Basierend auf dem Projekt und Attestierernamen hinzufügen.
Geben Sie in das Feld Projektname PROJECT_ID ein.
Geben Sie in das Feld Name des Attestierers
test-attestor
ein.Klicken Sie auf 1 Attestierer hinzufügen.
Klicken Sie auf Save Policy (Richtlinie speichern).
Weitere Informationen finden Sie unter Richtlinie über die Console 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.
Führen Sie den folgenden Befehl aus, um das Image bereitzustellen:
kubectl run hello-server --image gcr.io/google-samples/hello-app:1.0 --port 8080
Prüfen Sie, 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_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.
In dieser Anleitung erstellen Sie eine Attestierung für Beispiel-Images aus Container Registry und Artifact Registry.
So erstellen Sie eine Attestierung:
Legen Sie Variablen fest, die den Registrierungspfad und den Digest des Images sowie den Namen des Attestierers speichern:
Container Registry
IMAGE_PATH="gcr.io/google-samples/hello-app" IMAGE_DIGEST="sha256:c62ead5b8c15c231f9e786250b07909daf6c266d0fcddd93fea882eb722c3be4" ATTESTOR="test-attestor" 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" ATTESTOR="test-attestor" IMAGE_TO_ATTEST=${IMAGE_PATH}@${IMAGE_DIGEST}
Erstellen Sie die Attestierungsnutzlast:
Container Registry
gcloud container binauthz create-signature-payload \ --artifact-url=${IMAGE_PATH}@${IMAGE_DIGEST} > /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" } }
Artifact Registry
gcloud container binauthz create-signature-payload \ --artifact-url=${IMAGE_PATH}@${IMAGE_DIGEST} > /tmp/generated_payload.json
Die JSON-Nutzlastdatei hat folgenden Inhalt:
{ "critical": { "identity": { "docker-reference": "us-docker.pkg.dev/google-samples/containers/gke/hello-app" }, "image": { "docker-manifest-digest": "sha256:37e5287945774f27b418ce567cd77f4bbc9ef44a1bcd1a2312369f31f9cce567" }, "type": "Google cloud binauthz container signature" } }
Signieren Sie die Nutzlast mit dem privaten PKIX-Schlüssel und geben Sie eine Signaturdatei aus:
openssl dgst -sha256 -sign ${PRIVATE_KEY_FILE} /tmp/generated_payload.json > /tmp/ec_signature
Die Signaturdatei ist eine digital signierte Version der JSON-Nutzlastdatei, die Sie oben erstellt haben.
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
Dabei ist
PUBLIC_KEY_ID
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 den Digest zur Suche nach Attestierungen verwendet. Das Deployment des Images wird hier von der Binärautorisierung zugelassen, da die erforderliche Attestierung erstellt wurde.
Führen Sie den folgenden Befehl aus, um das Image bereitzustellen:
kubectl run hello-server --image ${IMAGE_PATH}@${IMAGE_DIGEST} --port 8080
Führen Sie den folgenden Befehl aus, um zu prüfen, 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
Führen Sie den folgenden Befehl aus, um den Pod zu löschen:
kubectl delete pod hello-server
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). - Image-Digests in Kubernetes-Manifesten verwenden
- Probelaufmodus aktivieren, um die Erzwingung zu deaktivieren