Binärautorisierung mithilfe von Cloud Build und GKE implementieren

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. Neuen Google Cloud-Nutzern steht möglicherweise eine kostenlose Testversion zur Verfügung.

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

  1. 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.

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

    Zur Projektauswahl

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

  4. Binary Authorization, Cloud Build, Cloud KMS, GKE, Artifact Registry, Artifact Analysis, Resource Manager, and Cloud Source Repositories APIs aktivieren.

    Aktivieren Sie die APIs

    5.

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

    Zur Projektauswahl

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

  7. Binary Authorization, Cloud Build, Cloud KMS, GKE, Artifact Registry, Artifact Analysis, Resource Manager, and Cloud Source Repositories APIs aktivieren.

    Aktivieren Sie die APIs

    8.

  8. Aktivieren Sie Cloud Shell in der Google Cloud Console.

    Cloud Shell aktivieren

    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.

    9. 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.

Diagramm: Architektur eines SDLC, bei dem eine einzelne Attestierung angewendet 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.

Diagramm: Architektur der CI-/CD-Pipeline mit drei Google Cloud-Produkten

Diese CI-/CD-Pipeline besteht aus den folgenden Schritten:

  1. Erstellt ein Container-Image mit Anwendungsquellcode.

  2. Überträgt das Container-Image per Push in Artifact Registry.

  3. 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.

  1. 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}

  2. 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.

  3. Legen Sie die Cloud Build-Projektnummer fest:

    export PROJECT_NUMBER="$(gcloud projects describe "${PROJECT_ID}" \
  --format='value(projectNumber)')"

  4. 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.

  1. 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

  2. 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

  3. 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.

  1. Erstellen Sie in Cloud Shell einen Cloud KMS-Schlüsselbund namens binauthz:

    gcloud kms keyrings create "binauthz" \
  --project "${PROJECT_ID}" \
  --location "${REGION}"

  2. 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"

  3. 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

  1. 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

  2. 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

  3. 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"

  4. 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}"

  5. 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"

  6. 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

  1. 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

  2. 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

  3. 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"

  4. 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}"

  5. 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"

  6. 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 in ALWAYS_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 von vulnz-attestor.

    • prod-cluster erfordert Attestierungen von vulnz-attestor und qa-attestor.

Weitere Informationen zu Richtlinien für die Binärautorisierung finden Sie in der Referenz zu YAML-Richtlinien.

  1. 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

  2. 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.

  1. 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}

  2. 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

  3. Erstellen Sie den Attestierer-Container namens attestor für das Scannen auf Sicherheitslücken und übertragen Sie ihn per Push in cloudbuild-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

  1. Erstellen Sie in Cloud Shell ein Cloud Source Repositories-Repository für die Beispielanwendung:

    gcloud source repos create hello-app \
  --project "${PROJECT_ID}"

  2. Klonen Sie das Repository lokal:

    gcloud source repos clone hello-app ~/hello-app \
  --project "${PROJECT_ID}"

  3. Kopieren Sie den Beispielcode in das Repository:

    cp -R ~/binauthz-tools/examples/hello-app/* ~/hello-app

  4. 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

  1. Öffnen Sie in der Google Cloud Console die Seite Triggers.

    Zur Seite "Trigger"

  2. Klicken Sie auf Repositories verwalten.

  3. Klicken Sie im Repository hello-app auf ... und wählen Sie Trigger hinzufügen aus.

  4. 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.

  5. Fügen Sie die folgenden Ersatzvariablen-Paare hinzu:

    • _COMPUTE_REGION mit dem Wert us-central1 (oder der Region, die Sie am Anfang ausgewählt haben).
    • _KMS_KEYRING mit dem Wert binauthz.
    • _KMS_LOCATION mit dem Wert us-central1 (oder der Region, die Sie am Anfang ausgewählt haben).
    • _PROD_CLUSTER mit dem Wert prod-cluster.
    • _QA_ATTESTOR mit dem Wert qa-attestor.
    • _QA_KMS_KEY mit dem Wert qa-signer.
    • _QA_KMS_KEY_VERSION mit dem Wert 1.
    • _STAGING_CLUSTER mit dem Wert staging-cluster.
    • _VULNZ_ATTESTOR mit dem Wert vulnz-attestor.
    • _VULNZ_KMS_KEY mit dem Wert vulnz-signer.
    • _VULNZ_KMS_KEY_VERSION mit dem Wert 1.

  6. 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.

  1. Ü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

  2. Öffnen Sie in der Google Cloud Console die Seite Verlauf.

    Zur Seite "Verlauf"

  3. Klicken Sie auf die letzte Ausführung von Cloud Build, um den Fortschritt der Build-Erstellung zu verfolgen.

    Screenshot: Build-Informationen

  4. Wenn das Deployment in staging-cluster abgeschlossen ist, rufen Sie die Seite Dienste auf.

    Zur Seite "Dienste"

  5. Klicken Sie auf den Link Endpunkte für die Anwendung, um zu überprüfen, ob sie funktioniert.

  6. Rufen Sie die Seite Repositories auf.

    Zur Seite "Images"

  7. Klicken Sie auf applications.

  8. Klicken Sie auf hello-app.

  9. Klicken Sie auf das Image, das Sie im Rahmen des Staging-Deployments geprüft haben.

    Screenshot: Name des geprüften Images

  10. Kopieren Sie den Digest-Wert aus den Image-Details. Diese Information wird im nächsten Schritt benötigt.

    Screenshot: Digest-Wert des Images

  11. Ersetzen Sie ... durch den Wert, den Sie aus den Image-Details kopiert haben, um die manuelle QA-Attestierung anzuwenden. Die Variable DIGEST muss das Format sha256: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}"

  12. Rufen Sie die Seite Dienste auf, um zu prüfen, ob die Anwendung bereitgestellt wurde.

    Zur Seite "Dienste"

  13. 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.

  1. Ändern Sie in Cloud Shell die Ausgabe von Hello World in Binary Authorization und das Basis-Image von distroless in debian:

    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

  2. Ü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

  3. Rufen Sie in der Google Cloud Console die Seite Verlauf auf, um den Status der CI-/CD-Pipeline zu beobachten.

    Zur Seite "Verlauf"

    Dieser Build bricht ab, weil im Image CVEs erkannt wurden.

  4. Rufen Sie die Seite Images auf, um die gefundenen CVEs zu untersuchen:

    Zur Seite "Images"

  5. Klicken Sie auf hello-app.

  6. Klicken Sie zum Prüfen der festgestellten CVEs auf die Zusammenfassung der Sicherheitslücken für das neueste Image.

    Screenshot: Link zur Zusammenfassung der Sicherheitslücken für ein aktuelles Image

  7. 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

  8. Rufen Sie in der Google Cloud Console die Seite Arbeitslasten auf.

    Zur Seite "Arbeitslasten"

    Screenshot: Image-Fehlerstatus

    Das Image konnte nicht bereitgestellt werden, da es nicht von vulnz-attestor und qa-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.

  1. Entfernen Sie in Cloud Shell die Kommentarzeichen vor der Break-Glass-Annotation im Kubernetes-Manifest:

    sed -i "31s/^#//" kubernetes/deployment.yaml

  2. Übernehmen Sie die Änderungen mit kubectl:

    kubectl apply -f kubernetes

  3. Rufen Sie in der Google Cloud Console die Seite Arbeitslasten auf, um zu prüfen, ob die Änderung im prod-cluster übernommen wurde.

    Zur Seite "Arbeitslasten"

    Der Deployment-Fehler wird jetzt nicht mehr angezeigt.

  4. Rufen Sie die Seite Dienste auf, um zu überprüfen, ob die Anwendung bereitgestellt wurde.

    Zur Seite "Dienste"

  5. 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

  1. Wechseln Sie in der Google Cloud Console zur Seite Ressourcen verwalten.

    Zur Seite „Ressourcen verwalten“

  2. Wählen Sie in der Projektliste das Projekt aus, das Sie löschen möchten, und klicken Sie dann auf Löschen.
  3. Geben Sie im Dialogfeld die Projekt-ID ein und klicken Sie auf Shut down (Beenden), um das Projekt zu löschen.

Nächste Schritte