In dieser Anleitung erfahren Sie, wie Sie Binärautorisierung für Google Kubernetes Engine (GKE) einrichten, konfigurieren und verwenden. Bei der Binärautorisierung werden Attestierungen für Container-Images erstellt, um zu prüfen, ob bestimmte Kriterien erfüllt sind, bevor die Images in GKE bereitgestellt werden.
Mit der Binärautorisierung kann beispielsweise geprüft werden, ob eine Anwendung Einheitentests bestanden hat oder ob sie mit einer spezifischen Gruppe von Systemen erstellt wurde. Weitere Informationen finden Sie unter Software Delivery Shield – Übersicht.
Diese Anleitung richtet sich an fortgeschrittene Anwender, die das Scannen auf Sicherheitslücken bei Containern und die Binärautorisierung sowie die Implementierung und Verwendung in einer CI-/CD-Pipeline besser verstehen möchten.
Bei dieser Anleitung wird davon ausgegangen, dass Sie mit den folgenden Themen und Technologien vertraut sind:
- Continuous Integration und Continuous Deployment
- Scannen auf CVE-Sicherheitslücken (Common Vulnerabilities and Exposures)
- GKE
- Artifact Registry
- Cloud Build
- Cloud Key Management Service (Cloud KMS)
Ziele
- GKE-Cluster für Staging und Produktion bereitstellen
- Mehrere Attestierer und Attestierungen erstellen
- CI-/CD-Pipeline mit Cloud Build bereitstellen
- Deployment-Pipeline testen
- Break-Glass-Prozess für Ausnahmezugriff entwickeln
Kosten
In diesem Dokument verwenden Sie die folgenden kostenpflichtigen Komponenten von Google Cloud:
Mit dem Preisrechner können Sie eine Kostenschätzung für Ihre voraussichtliche Nutzung vornehmen.
Nach Abschluss der in diesem Dokument beschriebenen Aufgaben können Sie weitere Kosten vermeiden, indem Sie die erstellten Ressourcen löschen. Weitere Informationen finden Sie unter Bereinigen.
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.
-
Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein.
-
Binary Authorization, Cloud Build, Cloud KMS, GKE, Artifact Registry, Artifact Analysis, Resource Manager, and Cloud Source Repositories APIs aktivieren.
-
Wählen Sie in der Google Cloud Console auf der Seite der Projektauswahl ein Google Cloud-Projekt aus oder erstellen Sie eines.
-
Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein.
-
Binary Authorization, Cloud Build, Cloud KMS, GKE, Artifact Registry, Artifact Analysis, Resource Manager, and Cloud Source Repositories APIs aktivieren.
-
Aktivieren Sie Cloud Shell in der Google Cloud Console.
Unten in der Google Cloud Console wird eine Cloud Shell-Sitzung gestartet und eine Eingabeaufforderung angezeigt. Cloud Shell ist eine Shell-Umgebung, in der das Google Cloud CLI bereits installiert ist und Werte für Ihr aktuelles Projekt bereits festgelegt sind. Das Initialisieren der Sitzung kann einige Sekunden dauern.
Alle Befehle in dieser Anleitung werden in Cloud Shell ausgeführt.
Architektur der CI-/CD-Pipeline
Ein wichtiger Aspekt des Software-Entwicklungslebenszyklus (Software Development Lifecycle, SDLC) besteht darin, durchzusetzen, dass bei der Anwendungsbereitstellung die von Ihrer Organisation genehmigten Prozesse eingehalten werden. Entsprechende Kontrollmechanismen können beispielsweise mit der Binärautorisierung in GKE eingerichtet werden. Bei der Binärautorisierung werden Container-Images zuerst mit Hinweisen versehen. Dann wird von GKE geprüft, ob die erforderlichen Hinweise vorhanden sind, bevor die Anwendung bereitgestellt werden kann.
Mit diesen Hinweisen, auch Attestierungen genannt, werden Aussagen über das Image getroffen. Diese Attestierungen sind vollständig konfigurierbar. Hier einige gängige Beispiele:
- Die Anwendung hat Einheitentests bestanden.
- Die Anwendung wurde vom Team für Qualitätssicherung (Quality Assurance, QA) geprüft.
- Die Anwendung wurde auf Sicherheitslücken gescannt und es wurden keine gefunden.
Das folgende Diagramm zeigt einen SDLC, in dem eine einzelne Attestierung angewendet wird, nachdem das Scannen auf Sicherheitslücken ohne erkannte Sicherheitslücken abgeschlossen wurde.
In dieser Anleitung erstellen Sie mit Cloud Source Repositories, Cloud Build, Artifact Registry und GKE eine CI/CD-Pipeline. Das folgende Diagramm veranschaulicht die CI-/CD-Pipeline.
Diese CI-/CD-Pipeline besteht aus den folgenden Schritten:
Erstellt ein Container-Image mit Anwendungsquellcode.
Überträgt das Container-Image per Push in Artifact Registry.
Mit Artefaktanalyse wird das Container-Image auf bekannte Sicherheitslücken und CVEs gescannt.
Wenn das Image keine CVEs mit einem Schweregradwert von über fünf aufweist, erhält das Image die Attestierung, dass es keine kritischen CVEs hat, und wird automatisch für das Staging bereitgestellt. Ein Wert von über fünf bedeutet, dass sich der Schweregrad der ermittelten Sicherheitslücken zwischen dem mittleren Bereich der Stufe "Mittel" und der Stufe "Kritisch" bewegt. Somit erfolgt keine Attestierung und kein Deployment.
Ein QA-Team untersucht die Anwendung im Staging-Cluster. Wenn sie die Anforderungen erfüllt, erfolgt eine manuelle Attestierung, dass die Qualität des Container-Images für das Deployment in der Produktion ausreicht. Die Produktionsmanifeste werden aktualisiert und die Anwendung wird im GKE-Produktionscluster bereitgestellt.
Die GKE-Cluster sind so konfiguriert, dass sie die Container-Images auf Attestierungen prüfen und Deployments ablehnen, die nicht die erforderlichen Attestierungen haben. Für den GKE-Staging-Cluster sind nur die Attestierung für das Scannen auf Sicherheitslücken erforderlich, für den GKE-Produktionscluster jedoch sowohl eine Attestierung für das Scannen auf Sicherheitslücken als auch eine QA-Attestierung.
In dieser Anleitung bauen Sie Fehler in die CI-/CD-Pipeline ein, um die Erzwingung dieses Verfahrens zu testen und zu verifizieren. Schließlich implementieren Sie einen Break-Glass-Prozess, mit dem im Notfall diese Deployment-Prüfungen in GKE umgangen werden.
Umgebung einrichten
In dieser Anleitung werden die folgenden Umgebungsvariablen verwendet. Sie können diese Werte an Ihre Anforderungen anpassen, aber bei sämtlichen Schritten in der Anleitung wird davon ausgegangen, dass diese Umgebungsvariablen vorhanden sind und einen gültigen Wert enthalten.
Legen Sie in Cloud Shell das Google Cloud-Projekt fest, in dem Sie alle in dieser Anleitung verwendeten Ressourcen bereitstellen und verwalten:
export PROJECT_ID="${DEVSHELL_PROJECT_ID}" gcloud config set project ${PROJECT_ID}
Legen Sie die Region fest, in der Sie diese Ressourcen bereitstellen:
export REGION="us-central1"
Der GKE-Cluster und die Cloud KMS-Schlüssel befinden sich in dieser Region. In dieser Anleitung wird die Region
us-central1
verwendet. Weitere Informationen zu Regionen finden Sie unter Geografie und Regionen.Legen Sie die Cloud Build-Projektnummer fest:
export PROJECT_NUMBER="$(gcloud projects describe "${PROJECT_ID}" \ --format='value(projectNumber)')"
Legen Sie die E-Mail-Adresse des Cloud Build-Dienstkontos fest:
export CLOUD_BUILD_SA_EMAIL="${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com"
GKE-Cluster erstellen
Sie erstellen zwei GKE-Cluster und gewähren IAM-Berechtigungen (Identity and Access Management), damit Cloud Build Anwendungen in GKE bereitstellen kann. Das Erstellen von GKE-Clustern kann einige Minuten dauern.
Erstellen Sie in Cloud Shell einen GKE-Cluster für das Staging:
gcloud container clusters create "staging-cluster" \ --project "${PROJECT_ID}" \ --machine-type "n1-standard-1" \ --region "${REGION}" \ --num-nodes "1" \ --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE
Erstellen Sie einen GKE-Cluster für die Produktion:
gcloud container clusters create "prod-cluster" \ --project "${PROJECT_ID}" \ --machine-type "n1-standard-1" \ --region "${REGION}" \ --num-nodes "1" \ --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE
Gewähren Sie dem Cloud Build-Dienstkonto die Berechtigung zum Deployment in GKE:
gcloud projects add-iam-policy-binding "${PROJECT_ID}" \ --member "serviceAccount:${CLOUD_BUILD_SA_EMAIL}" \ --role "roles/container.developer"
Signaturschlüssel erstellen
Erstellen Sie zwei asymmetrische Cloud KMS-Schlüssel zum Signieren von Attestierungen.
Erstellen Sie in Cloud Shell einen Cloud KMS-Schlüsselbund namens
binauthz
:gcloud kms keyrings create "binauthz" \ --project "${PROJECT_ID}" \ --location "${REGION}"
Erstellen Sie einen asymmetrischen Cloud KMS-Schlüssel mit dem Namen
vulnz-signer
, der zum Signieren und Verifizieren von Attestierungen für das Scannen auf Sicherheitslücken verwendet wird:gcloud kms keys create "vulnz-signer" \ --project "${PROJECT_ID}" \ --location "${REGION}" \ --keyring "binauthz" \ --purpose "asymmetric-signing" \ --default-algorithm "rsa-sign-pkcs1-4096-sha512"
Erstellen Sie einen asymmetrischen Cloud KMS-Schlüssel mit dem Namen
qa-signer
, um QA-Attestierungen zu signieren und zu verifizieren:gcloud kms keys create "qa-signer" \ --project "${PROJECT_ID}" \ --location "${REGION}" \ --keyring "binauthz" \ --purpose "asymmetric-signing" \ --default-algorithm "rsa-sign-pkcs1-4096-sha512"
Attestierungen konfigurieren
Sie erstellen die Hinweise, mit denen die Container-Images versehen sind, und erteilen dem Cloud Build-Dienstkonto die Berechtigung zum Aufrufen von Hinweisen, zum Anhängen von Hinweisen und zum Erstellen der Attestierer mithilfe der Schlüssel aus den vorherigen Schritten.
Attestierung für das Scannen auf Sicherheitslücken erstellen
Erstellen Sie in Cloud Shell einen Artefaktanalyse-Hinweis mit dem Namen
vulnz-note
:curl "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/?noteId=vulnz-note" \ --request "POST" \ --header "Content-Type: application/json" \ --header "Authorization: Bearer $(gcloud auth print-access-token)" \ --header "X-Goog-User-Project: ${PROJECT_ID}" \ --data-binary @- <<EOF { "name": "projects/${PROJECT_ID}/notes/vulnz-note", "attestation": { "hint": { "human_readable_name": "Vulnerability scan note" } } } EOF
Gewähren Sie dem Cloud Build-Dienstkonto die Berechtigung zum Anzeigen und Anhängen des Hinweises
vulnz-note
an Container-Images:curl "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/vulnz-note:setIamPolicy" \ --request POST \ --header "Content-Type: application/json" \ --header "Authorization: Bearer $(gcloud auth print-access-token)" \ --header "X-Goog-User-Project: ${PROJECT_ID}" \ --data-binary @- <<EOF { "resource": "projects/${PROJECT_ID}/notes/vulnz-note", "policy": { "bindings": [ { "role": "roles/containeranalysis.notes.occurrences.viewer", "members": [ "serviceAccount:${CLOUD_BUILD_SA_EMAIL}" ] }, { "role": "roles/containeranalysis.notes.attacher", "members": [ "serviceAccount:${CLOUD_BUILD_SA_EMAIL}" ] } ] } } EOF
Erstellen Sie den Attestierer zum Scannen auf Sicherheitslücken:
gcloud container binauthz attestors create "vulnz-attestor" \ --project "${PROJECT_ID}" \ --attestation-authority-note-project "${PROJECT_ID}" \ --attestation-authority-note "vulnz-note" \ --description "Vulnerability scan attestor"
Fügen Sie den öffentlichen Schlüssel für den Signaturschlüssel des Attestierers hinzu:
gcloud beta container binauthz attestors public-keys add \ --project "${PROJECT_ID}" \ --attestor "vulnz-attestor" \ --keyversion "1" \ --keyversion-key "vulnz-signer" \ --keyversion-keyring "binauthz" \ --keyversion-location "${REGION}" \ --keyversion-project "${PROJECT_ID}"
Gewähren Sie dem Cloud Build-Dienstkonto die Berechtigung, Attestierungen von
vulnz-attestor
anzuzeigen:gcloud container binauthz attestors add-iam-policy-binding "vulnz-attestor" \ --project "${PROJECT_ID}" \ --member "serviceAccount:${CLOUD_BUILD_SA_EMAIL}" \ --role "roles/binaryauthorization.attestorsViewer"
Gewähren Sie dem Cloud Build-Dienstkonto die Berechtigung, Objekte mit dem Schlüssel
vulnz-signer
zu signieren:gcloud kms keys add-iam-policy-binding "vulnz-signer" \ --project "${PROJECT_ID}" \ --location "${REGION}" \ --keyring "binauthz" \ --member "serviceAccount:${CLOUD_BUILD_SA_EMAIL}" \ --role 'roles/cloudkms.signerVerifier'
QA-Attestierung erstellen
Erstellen Sie in Cloud Shell einen Artefaktanalyse-Hinweis mit dem Namen
qa-note
:curl "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/?noteId=qa-note" \ --request "POST" \ --header "Content-Type: application/json" \ --header "Authorization: Bearer $(gcloud auth print-access-token)" \ --header "X-Goog-User-Project: ${PROJECT_ID}" \ --data-binary @- <<EOF { "name": "projects/${PROJECT_ID}/notes/qa-note", "attestation": { "hint": { "human_readable_name": "QA note" } } } EOF
Gewähren Sie dem Cloud Build-Dienstkonto die Berechtigung zum Anzeigen und Anhängen des Hinweises
qa-note
an Container-Images:curl "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/qa-note:setIamPolicy" \ --request POST \ --header "Content-Type: application/json" \ --header "Authorization: Bearer $(gcloud auth print-access-token)" \ --header "X-Goog-User-Project: ${PROJECT_ID}" \ --data-binary @- <<EOF { "resource": "projects/${PROJECT_ID}/notes/qa-note", "policy": { "bindings": [ { "role": "roles/containeranalysis.notes.occurrences.viewer", "members": [ "serviceAccount:${CLOUD_BUILD_SA_EMAIL}" ] }, { "role": "roles/containeranalysis.notes.attacher", "members": [ "serviceAccount:${CLOUD_BUILD_SA_EMAIL}" ] } ] } } EOF
Erstellen Sie den QA-Attestierer:
gcloud container binauthz attestors create "qa-attestor" \ --project "${PROJECT_ID}" \ --attestation-authority-note-project "${PROJECT_ID}" \ --attestation-authority-note "qa-note" \ --description "QA attestor"
Fügen Sie den öffentlichen Schlüssel für den Signaturschlüssel des Attestierers hinzu:
gcloud beta container binauthz attestors public-keys add \ --project "${PROJECT_ID}" \ --attestor "qa-attestor" \ --keyversion "1" \ --keyversion-key "qa-signer" \ --keyversion-keyring "binauthz" \ --keyversion-location "${REGION}" \ --keyversion-project "${PROJECT_ID}"
Gewähren Sie dem Cloud Build-Dienstkonto die Berechtigung, Attestierungen von
qa-attestor
anzuzeigen:gcloud container binauthz attestors add-iam-policy-binding "qa-attestor" \ --project "${PROJECT_ID}" \ --member "serviceAccount:${CLOUD_BUILD_SA_EMAIL}" \ --role "roles/binaryauthorization.attestorsViewer"
Gewähren Sie dem QA-Team die Berechtigung zum Signieren von Attestierungen:
gcloud kms keys add-iam-policy-binding "qa-signer" \ --project "${PROJECT_ID}" \ --location "${REGION}" \ --keyring "binauthz" \ --member "group:qa-team@example.com" \ --role 'roles/cloudkms.signerVerifier'
Richtlinie für Binärautorisierungen festlegen
Auch wenn Sie die GKE-Cluster mit --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE
erstellt haben, müssen Sie eine Richtlinie einrichten, die GKE anweist, welche Attestierungen die Binärdateien zum Ausführen im Cluster benötigen. Die Richtlinien für die Binärautorisierung befinden sich auf Projektebene, enthalten aber die Konfiguration für die Clusterebene.
Mit der folgenden Richtlinie wird die Standardrichtlinie wie beschrieben geändert:
Ändert die Standardeinstellung
evaluationMode
inALWAYS_DENY
. Nur ausgenommene Images oder Images mit den erforderlichen Attestierungen dürfen im Cluster ausgeführt werden.Aktiviert
globalPolicyEvaluationMode
, wodurch die standardmäßige Zulassungsliste so geändert wird, dass sie nur von Google bereitgestellte System-Images enthält.Definiert die folgenden Clusterzugangsregeln:
staging-cluster
erfordert Attestierungen vonvulnz-attestor
.prod-cluster
erfordert Attestierungen vonvulnz-attestor
undqa-attestor
.
Weitere Informationen zu Richtlinien für die Binärautorisierung finden Sie in der Referenz zu YAML-Richtlinien.
Erstellen Sie in Cloud Shell eine YAML-Datei, mit der die Binärautorisierungsrichtlinie für das Google Cloud-Projekt beschrieben wird:
cat > ./binauthz-policy.yaml <<EOF admissionWhitelistPatterns: - namePattern: docker.io/istio/* defaultAdmissionRule: enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG evaluationMode: ALWAYS_DENY globalPolicyEvaluationMode: ENABLE clusterAdmissionRules: # Staging cluster ${REGION}.staging-cluster: evaluationMode: REQUIRE_ATTESTATION enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG requireAttestationsBy: - projects/${PROJECT_ID}/attestors/vulnz-attestor # Production cluster ${REGION}.prod-cluster: evaluationMode: REQUIRE_ATTESTATION enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG requireAttestationsBy: - projects/${PROJECT_ID}/attestors/vulnz-attestor - projects/${PROJECT_ID}/attestors/qa-attestor EOF
Laden Sie die neue Richtlinie in das Google Cloud-Projekt hoch:
gcloud container binauthz policy import ./binauthz-policy.yaml \ --project "${PROJECT_ID}"
Prüfung zum Scannen auf Sicherheitslücken erstellen und API aktivieren
Erstellen Sie ein Container-Image, das als Build-Schritt in Cloud Build verwendet wird. Dieser Container vergleicht die Schweregradwerte erkannter Sicherheitslücken mit dem konfigurierten Grenzwert. Wenn der Wert im Rahmen des Grenzwerts liegt, erstellt Cloud Build eine Attestierung für den Container. Wenn der Wert außerhalb des Grenzwerts liegt, schlägt der Build fehl und es wird keine Attestierung erstellt.
Erstellen Sie in Cloud Shell ein neues Artifact Registry-Repository zum Speichern des Attestierer-Images:
gcloud artifacts repositories create cloudbuild-helpers \ --repository-format=DOCKER --location=${REGION}
Klonen Sie die Tools für die Binärautorisierung und die Quelle der Beispielanwendung:
git clone https://github.com/GoogleCloudPlatform/gke-binary-auth-tools ~/binauthz-tools
Erstellen Sie den Attestierer-Container namens
attestor
für das Scannen auf Sicherheitslücken und übertragen Sie ihn per Push incloudbuild-helpers
Artifact Registry:gcloud builds submit \ --project "${PROJECT_ID}" \ --tag "us-central1-docker.pkg.dev/${PROJECT_ID}/cloudbuild-helpers/attestor" \ ~/binauthz-tools
Cloud Build-Pipeline einrichten
Erstellen Sie mit Cloud Source Repositories ein Repository und in Cloud Build einen Trigger für die Beispielanwendung und die Kubernetes-Manifeste.
Cloud Source Repositories und Artifact Registry-Repository für „hello-app“ erstellen
Erstellen Sie in Cloud Shell ein Cloud Source Repositories-Repository für die Beispielanwendung:
gcloud source repos create hello-app \ --project "${PROJECT_ID}"
Klonen Sie das Repository lokal:
gcloud source repos clone hello-app ~/hello-app \ --project "${PROJECT_ID}"
Kopieren Sie den Beispielcode in das Repository:
cp -R ~/binauthz-tools/examples/hello-app/* ~/hello-app
Erstellen Sie ein neues Artifact Registry-Repository zum Speichern von Anwendungs-Images:
gcloud artifacts repositories create applications \ --repository-format=DOCKER --location=${REGION}
Cloud Build-Trigger für "hello-app" erstellen
Öffnen Sie in der Google Cloud Console die Seite Triggers.
Klicken Sie auf Repositories verwalten.
Klicken Sie im Repository
hello-app
auf ... und wählen Sie Trigger hinzufügen aus.Geben Sie im Fenster Triggereinstellungen die folgenden Details ein:
- Geben Sie im Feld Name
build-vulnz-deploy
ein. - Wählen Sie für Ereignis die Option Per Push zu Zweig übertragen aus.
- Wählen Sie im Feld Repository aus dem Menü
hello-app
aus. - Geben Sie im Feld Branch den Wert
master
ein. - Für Konfiguration Wählen Sie die Cloud Build-Konfigurationsdatei (YAML oder JSON) aus.
- Wählen Sie unter Speicherort die Option Repository aus und geben Sie den Standardwert
/cloudbuild.yaml
ein.
- Geben Sie im Feld Name
Fügen Sie die folgenden Ersatzvariablen-Paare hinzu:
_COMPUTE_REGION
mit dem Wertus-central1
(oder der Region, die Sie am Anfang ausgewählt haben)._KMS_KEYRING
mit dem Wertbinauthz
._KMS_LOCATION
mit dem Wertus-central1
(oder der Region, die Sie am Anfang ausgewählt haben)._PROD_CLUSTER
mit dem Wertprod-cluster
._QA_ATTESTOR
mit dem Wertqa-attestor
._QA_KMS_KEY
mit dem Wertqa-signer
._QA_KMS_KEY_VERSION
mit dem Wert1
._STAGING_CLUSTER
mit dem Wertstaging-cluster
._VULNZ_ATTESTOR
mit dem Wertvulnz-attestor
._VULNZ_KMS_KEY
mit dem Wertvulnz-signer
._VULNZ_KMS_KEY_VERSION
mit dem Wert1
.
Klicken Sie auf Erstellen.
Cloud Build-Pipeline testen
Testen Sie die CI-/CD-Pipeline. Übertragen Sie dazu die Beispielanwendung per Commit und Push in das Repository von Cloud Source Repositories. Cloud Build erkennt die Änderung, erstellt die Anwendung und stellt sie im staging-cluster
bereit. Die Pipeline wartet bis zu 10 Minuten auf die QA-Prüfung. Nachdem das Deployment vom QA-Team geprüft wurde, wird der Prozess fortgesetzt und die Kubernetes-Produktionsmanifeste werden aktualisiert. Danach stellt Cloud Build die Anwendung im prod-cluster
bereit.
Übertragen Sie die
hello-app
-Dateien in Cloud Shell per Commit und Push in das Repository von Cloud Source Repositories, um einen Build auszulösen:cd ~/hello-app git add . git commit -m "Initial commit" git push origin master
Öffnen Sie in der Google Cloud Console die Seite Verlauf.
Klicken Sie auf die letzte Ausführung von Cloud Build, um den Fortschritt der Build-Erstellung zu verfolgen.
Wenn das Deployment in
staging-cluster
abgeschlossen ist, rufen Sie die Seite Dienste auf.Klicken Sie auf den Link Endpunkte für die Anwendung, um zu überprüfen, ob sie funktioniert.
Rufen Sie die Seite Repositories auf.
Klicken Sie auf
applications
.Klicken Sie auf
hello-app
.Klicken Sie auf das Image, das Sie im Rahmen des Staging-Deployments geprüft haben.
Kopieren Sie den Digest-Wert aus den Image-Details. Diese Information wird im nächsten Schritt benötigt.
Ersetzen Sie
...
durch den Wert, den Sie aus den Image-Details kopiert haben, um die manuelle QA-Attestierung anzuwenden. Die VariableDIGEST
muss das Formatsha256:hash-value
haben.Beim Build-Schritt
Await QA attestation
wird auch ein Befehl ausgegeben, der kopiert und eingefügt werden kann (siehe unten).DIGEST="sha256:..." # Replace with your value gcloud beta container binauthz attestations sign-and-create \ --project "${PROJECT_ID}" \ --artifact-url "${REGION}-docker.pkg.dev/${PROJECT_ID}/applications/hello-app@${DIGEST}" \ --attestor "qa-attestor" \ --attestor-project "${PROJECT_ID}" \ --keyversion "1" \ --keyversion-key "qa-signer" \ --keyversion-location "${REGION}" \ --keyversion-keyring "binauthz" \ --keyversion-project "${PROJECT_ID}"
Rufen Sie die Seite Dienste auf, um zu prüfen, ob die Anwendung bereitgestellt wurde.
Klicken Sie zum Aufrufen der Anwendung auf den Endpunktlink.
Image ohne Attestierungen bereitstellen
Bisher gab es in der Beispielanwendung keine Sicherheitslücken. Aktualisieren Sie die Anwendung, sodass eine andere Nachricht ausgegeben wird, und ändern Sie das Basis-Image.
Ändern Sie in Cloud Shell die Ausgabe von
Hello World
inBinary Authorization
und das Basis-Image vondistroless
indebian
:cd ~/hello-app sed -i "s/Hello World/Binary Authorization/g" main.go sed -i "s/FROM gcr\.io\/distroless\/static-debian11/FROM debian/g" Dockerfile
Übernehmen Sie die Änderungen per Commit und übertragen Sie sie per Push:
git add . git commit -m "Change message and base image" git push origin master
Rufen Sie in der Google Cloud Console die Seite Verlauf auf, um den Status der CI-/CD-Pipeline zu beobachten.
Dieser Build bricht ab, weil im Image CVEs erkannt wurden.
Rufen Sie die Seite Images auf, um die gefundenen CVEs zu untersuchen:
Klicken Sie auf
hello-app
.Klicken Sie zum Prüfen der festgestellten CVEs auf die Zusammenfassung der Sicherheitslücken für das neueste Image.
Versuchen Sie in Cloud Shell, das neue Image ohne Attestierung für das Scannen auf Sicherheitslücken in der Produktion bereitzustellen:
export SHA_DIGEST="[SHA_DIGEST_VALUE]" cd ~/hello-app sed "s/REGION/${REGION}/g" kubernetes/deployment.yaml.tpl | \ sed "s/GOOGLE_CLOUD_PROJECT/${PROJECT_ID}/g" | \ sed -e "s/DIGEST/${SHA_DIGEST}/g" > kubernetes/deployment.yaml gcloud container clusters get-credentials \ --project=${PROJECT_ID} \ --region="${REGION}" prod-cluster kubectl apply -f kubernetes
Rufen Sie in der Google Cloud Console die Seite Arbeitslasten auf.
Das Image konnte nicht bereitgestellt werden, da es nicht von
vulnz-attestor
undqa-attestor
signiert wurde.
Break-Glass-Prozess
Gelegentlich müssen Sie Änderungen außerhalb des normalen Workflows zulassen. Die Pod-Definition wird dann mit einem Break-Glass-Richtlinien-Flag versehen, um Image-Deployments ohne die erforderlichen Attestierungen zuzulassen. Wenn Sie dieses Flag aktivieren, prüft GKE zwar weiterhin, ob die erforderlichen Attestierungen vorhanden sind, lässt jedoch das Deployment der Container-Images zu und speichert etwaige Verstöße in Logs.
Weitere Informationen zum Umgehen von Attestierungsprüfungen finden Sie unter Richtlinie überschreiben.
Entfernen Sie in Cloud Shell die Kommentarzeichen vor der Break-Glass-Annotation im Kubernetes-Manifest:
sed -i "31s/^#//" kubernetes/deployment.yaml
Übernehmen Sie die Änderungen mit
kubectl
:kubectl apply -f kubernetes
Rufen Sie in der Google Cloud Console die Seite Arbeitslasten auf, um zu prüfen, ob die Änderung im
prod-cluster
übernommen wurde.Der Deployment-Fehler wird jetzt nicht mehr angezeigt.
Rufen Sie die Seite Dienste auf, um zu überprüfen, ob die Anwendung bereitgestellt wurde.
Klicken Sie zum Aufrufen der Anwendung auf den Endpunktlink.
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.
Projekt löschen
- Wechseln Sie in der Google Cloud Console zur Seite Ressourcen verwalten.
- Wählen Sie in der Projektliste das Projekt aus, das Sie löschen möchten, und klicken Sie dann auf Löschen.
- Geben Sie im Dialogfeld die Projekt-ID ein und klicken Sie auf Shut down (Beenden), um das Projekt zu löschen.
Nächste Schritte
- Best Practices für Containererstellung
- Container-Webanwendung bereitstellen
- Kontinuierliche Bereitstellung im GitOps-Stil mit Cloud Build
- Verwaltete Basis-Images
- Referenzarchitekturen, Diagramme und Best Practices zu Google Cloud kennenlernen. Weitere Informationen zu Cloud Architecture Center