GSP1183

Übersicht

Mit der Binärautorisierung wird die Sicherheit beim Deployment überprüft. So werden nur vertrauenswürdige Container-Images in der Google Kubernetes Engine (GKE) oder Cloud Run bereitgestellt. Sie können dabei festlegen, dass die Images während des Entwicklungsprozesses von vertrauenswürdigen Stellen signiert werden, und dann beim Deployment die Signaturprüfung erzwingen. Damit haben Sie eine stärkere Kontrolle über die Containerumgebung und sorgen dafür, dass nur verifizierte Images in den Build- und Release-Prozess eingebunden werden.

Das folgende Diagramm zeigt die Komponenten in einer Einrichtung mit Binärautorisierung/Cloud Build:

Cloud Build-Pipeline, die eine Attestierung der Binärautorisierung erstellt

In dieser Pipeline gilt:

1. Der Code zum Erstellen des Container-Images wird in ein Quell-Repository wie Cloud Source Repositories übertragen.
2. Das CI-Tool (Continuous Integration) Cloud Build erstellt und testet den Container.
3. Der Build überträgt das Container-Image per Push an Container Registry oder eine andere Registry, in der Ihre erstellten Images gespeichert sind.
4. Cloud Key Management Service, der die Schlüsselverwaltung für das kryptografische Schlüsselpaar bereitstellt, signiert das Container-Image. Die resultierende Signatur wird dann in einer neu erstellten Attestierung gespeichert.
5. Bei der Bereitstellung prüft der Attestierer die Attestierung mit dem öffentlichen Schlüssel aus dem Schlüsselpaar. Die Binärautorisierung erzwingt die Richtlinie. Dazu sind signierte Attestierungen zum Bereitstellen des Container-Images erforderlich.

In diesem Lab lernen Sie die Tools und Techniken kennen, mit denen Sie bereitgestellte Artefakte schützen können. In diesem Lab geht es um Artefakte (Container), nachdem sie erstellt, aber noch nicht in einer bestimmten Umgebung bereitgestellt wurden.

Lerninhalte

• Image signieren
• Richtlinien für die Zugangssteuerung
• Gescannte Images signieren
• Signierte Images autorisieren
• Blockierte unsignierte Images

Einrichtung und Anforderungen

Vor dem Klick auf „Lab starten“

Lesen Sie diese Anleitung. Labs sind zeitlich begrenzt und können nicht pausiert werden. Der Timer beginnt zu laufen, wenn Sie auf Lab starten klicken, und zeigt Ihnen, wie lange die Ressourcen für das Lab verfügbar sind.

In diesem praxisorientierten Lab können Sie die Lab-Aktivitäten in einer echten Cloud-Umgebung selbst durchführen – nicht in einer Simulations- oder Demo-Umgebung. Dazu erhalten Sie neue, temporäre Anmeldedaten, mit denen Sie für die Dauer des Labs auf Google Cloud zugreifen können.

Für dieses Lab benötigen Sie Folgendes:

• Einen Standardbrowser (empfohlen wird Chrome)

Hinweis: Nutzen Sie den privaten oder Inkognitomodus, um dieses Lab durchzuführen. So wird verhindert, dass es zu Konflikten zwischen Ihrem persönlichen Konto und dem Teilnehmerkonto kommt und zusätzliche Gebühren für Ihr persönliches Konto erhoben werden.

• Zeit für die Durchführung des Labs – denken Sie daran, dass Sie ein begonnenes Lab nicht unterbrechen können.

Hinweis: Wenn Sie über ein persönliches Google Cloud-Konto oder -Projekt verfügen, verwenden Sie es nicht für dieses Lab. So werden zusätzliche Kosten für Ihr Konto vermieden.

Lab starten und bei der Google Cloud Console anmelden

1. Klicken Sie auf Lab starten. Wenn Sie für das Lab bezahlen müssen, wird ein Pop-up-Fenster geöffnet, in dem Sie Ihre Zahlungsmethode auswählen können. Auf der linken Seite befindet sich der Bereich Details zum Lab mit diesen Informationen:

   • Schaltfläche Google Cloud Console öffnen
   • Restzeit
   • Temporäre Anmeldedaten für das Lab
   • Ggf. weitere Informationen für dieses Lab

2. Klicken Sie auf Google Cloud Console öffnen (oder klicken Sie mit der rechten Maustaste und wählen Sie Link in Inkognitofenster öffnen aus, wenn Sie Chrome verwenden).

   Im Lab werden Ressourcen aktiviert. Anschließend wird ein weiterer Tab mit der Seite Anmelden geöffnet.

   Tipp: Ordnen Sie die Tabs nebeneinander in separaten Fenstern an.

   Hinweis: Wird das Dialogfeld Konto auswählen angezeigt, klicken Sie auf Anderes Konto verwenden.

3. Kopieren Sie bei Bedarf den folgenden Nutzernamen und fügen Sie ihn in das Dialogfeld Anmelden ein.

   {{{user_0.username | "Username"}}}

   Sie finden den Nutzernamen auch im Bereich Details zum Lab.

4. Klicken Sie auf Weiter.

5. Kopieren Sie das folgende Passwort und fügen Sie es in das Dialogfeld Willkommen ein.

   {{{user_0.password | "Password"}}}

   Sie finden das Passwort auch im Bereich Details zum Lab.

6. Klicken Sie auf Weiter.

   Wichtig: Sie müssen die für das Lab bereitgestellten Anmeldedaten verwenden. Nutzen Sie nicht die Anmeldedaten Ihres Google Cloud-Kontos. Hinweis: Wenn Sie Ihr eigenes Google Cloud-Konto für dieses Lab nutzen, können zusätzliche Kosten anfallen.

7. Klicken Sie sich durch die nachfolgenden Seiten:

   • Akzeptieren Sie die Nutzungsbedingungen.
   • Fügen Sie keine Wiederherstellungsoptionen oder Zwei-Faktor-Authentifizierung hinzu (da dies nur ein temporäres Konto ist).
   • Melden Sie sich nicht für kostenlose Testversionen an.

Nach wenigen Augenblicken wird die Google Cloud Console in diesem Tab geöffnet.

Hinweis: Wenn Sie sich eine Liste der Google Cloud-Produkte und ‑Dienste ansehen möchten, klicken Sie oben links auf das Navigationsmenü.

Cloud Shell aktivieren

Cloud Shell ist eine virtuelle Maschine, auf der Entwicklertools installiert sind. Sie bietet ein Basisverzeichnis mit 5 GB nichtflüchtigem Speicher und läuft auf Google Cloud. Mit Cloud Shell erhalten Sie Befehlszeilenzugriff auf Ihre Google Cloud-Ressourcen.

1. Klicken Sie oben in der Google Cloud Console auf Cloud Shell aktivieren .

Wenn Sie verbunden sind, sind Sie bereits authentifiziert und das Projekt ist auf Ihre Project_ID, eingestellt. Die Ausgabe enthält eine Zeile, in der die Project_ID für diese Sitzung angegeben ist:

Ihr Cloud-Projekt in dieser Sitzung ist festgelegt als {{{project_0.project_id | "PROJECT_ID"}}}

gcloud ist das Befehlszeilentool für Google Cloud. Das Tool ist in Cloud Shell vorinstalliert und unterstützt die Tab-Vervollständigung.

2. (Optional) Sie können den aktiven Kontonamen mit diesem Befehl auflisten:

gcloud auth list

3. Klicken Sie auf Autorisieren.

Ausgabe:

ACTIVE: * ACCOUNT: {{{user_0.username | "ACCOUNT"}}} Um das aktive Konto festzulegen, führen Sie diesen Befehl aus: $ gcloud config set account `ACCOUNT`

4. (Optional) Sie können die Projekt-ID mit diesem Befehl auflisten:

gcloud config list project

Ausgabe:

[core] project = {{{project_0.project_id | "PROJECT_ID"}}} Hinweis: Die vollständige Dokumentation für gcloud finden Sie in Google Cloud in der Übersicht zur gcloud CLI.

Umgebung einrichten

Legen Sie in Cloud Shell Ihre Projekt-ID und die Projektnummer für Ihr Projekt fest. Speichern Sie diese als die Variablen PROJECT_ID und PROJECT_NUMBER ab:

export PROJECT_ID=$(gcloud config get-value project) export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID \ --format='value(projectNumber)')

Dienste aktivieren

Aktivieren Sie alle erforderlichen Dienste:

gcloud services enable \ cloudkms.googleapis.com \ cloudbuild.googleapis.com \ container.googleapis.com \ containerregistry.googleapis.com \ artifactregistry.googleapis.com \ containerscanning.googleapis.com \ ondemandscanning.googleapis.com \ binaryauthorization.googleapis.com

Aufgabe 1: Artifact Registry-Repository erstellen

In diesem Lab verwenden Sie Artifact Registry zum Speichern und Scannen Ihrer Images.

1. Erstellen Sie das Repository mit dem folgenden Befehl:

gcloud artifacts repositories create artifact-scanning-repo \ --repository-format=docker \ --location={{{ project_0.default_region | "REGION" }}} \ --description="Docker repository"

2. Konfigurieren Sie Docker so, dass Ihre gcloud-Anmeldedaten für den Zugriff auf Artifact Registry verwendet werden:

gcloud auth configure-docker {{{ project_0.default_region | "REGION" }}}-docker.pkg.dev

3. Erstellen Sie ein Arbeitsverzeichnis und wechseln Sie in dieses Verzeichnis:

mkdir vuln-scan && cd vuln-scan

4. Als Nächstes definieren Sie ein Beispiel-Image. Erstellen Sie eine Datei mit dem Namen Dockerfile mit folgendem Inhalt:

cat > ./Dockerfile << EOF FROM python:3.8-alpine # App WORKDIR /app COPY . ./ RUN pip3 install Flask==2.1.0 RUN pip3 install gunicorn==20.1.0 RUN pip3 install Werkzeug==2.2.2 CMD exec gunicorn --bind :\$PORT --workers 1 --threads 8 main:app EOF

5. Erstellen Sie eine Datei mit dem Namen main.py und dem folgenden Inhalt:

cat > ./main.py << EOF import os from flask import Flask app = Flask(__name__) @app.route("/") def hello_world(): name = os.environ.get("NAME", "Worlds") return "Hello {}!".format(name) if __name__ == "__main__": app.run(debug=True, host="0.0.0.0", port=int(os.environ.get("PORT", 8080))) EOF

6. Mit Cloud Build können Sie Ihren Container erstellen und automatisch per Push in Artifact Registry übertragen.

gcloud builds submit . -t {{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image

Klicken Sie auf Fortschritt prüfen. Erstellen Sie ein Artifact Registry-Repository.

Aufgabe 2: Image signieren

Was ist ein Attestierer?

• Diese Person oder dieser Prozess ist für ein Glied in der Vertrauenskette des Systems verantwortlich.
• Während des Genehmigungsprozesses wird ein Image mit einem kryptografischen Schlüssel signiert.
• Während der Ersteller die Richtlinie auf einer abstrakten Ebene festlegt, ist der Attestor für die konkrete Durchsetzung eines Aspekts der Richtlinie verantwortlich.
• Das kann eine echte Person wie ein QA-Tester oder ein Manager oder ein Bot in einem CI-System sein.
• Die Sicherheit des Systems hängt von ihrer Vertrauenswürdigkeit ab. Daher ist es wichtig, dass ihre privaten Schlüssel sicher aufbewahrt werden.

Jede dieser Rollen kann eine einzelne Person oder ein Team in Ihrer Organisation darstellen. In einer Produktionsumgebung werden diese Rollen wahrscheinlich von separaten Google Cloud Platform-Projekten verwaltet und der Zugriff auf Ressourcen wird mithilfe von Cloud IAM jeweils nur eingeschränkt freigegeben.

Attestoren in Binärautorisierung werden zusätzlich zur Cloud Container Analysis API implementiert. Daher ist es wichtig, die Funktionsweise zu beschreiben, bevor Sie fortfahren. Die Container Analysis API wurde entwickelt, damit Sie Metadaten bestimmten Container-Images zuordnen können.

Beispielsweise könnte eine Notiz erstellt werden, um die Heartbleed-Sicherheitslücke zu verfolgen. Sicherheitsanbieter erstellen dann Scanner, um Container-Images auf die Sicherheitslücke zu testen, und erstellen für jeden kompromittierten Container einen Hinweis.

Container Analysis wurde nicht nur für das Erfassen von Sicherheitslücken, sondern auch als generische Metadata API entwickelt. Die Binärautorisierung verwendet Container Analysis, um Signaturen den Container-Images zuzuordnen, die sie prüfen. Eine Container Analysis-Notiz wird verwendet, um einen einzelnen Attestierer darzustellen. Hinweise werden erstellt und jedem Container zugeordnet, den der Attestierer genehmigt hat.

In der Binary Authorization API werden die Konzepte „Attestierer“ und „Attestierungen“ verwendet. Diese werden jedoch mithilfe der entsprechenden Notizen und Hinweise in der Container Analysis API implementiert.

Attestier-Hinweis erstellen

Ein Attestier-Hinweis ist einfach ein kleiner Datenteil, der als Label für die Art der angewendeten Signatur dient. Ein Hinweis kann sich beispielsweise auf einen Scan auf Sicherheitslücken beziehen während ein anderer für die QA-Freigabe verwendet werden kann. Während des Signierungsprozesses wird auf den Hinweis Bezug genommen.

1. Erstellen Sie einen Hinweis:

cat > ./vulnz_note.json << EOM { "attestation": { "hint": { "human_readable_name": "Container Vulnerabilities attestation authority" } } } EOM

2. Speichern Sie den Hinweis:

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

3. Bestätigen Sie den Hinweis:

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

Ihr Hinweis wird jetzt in der Container Analysis API gespeichert.

4. Attestierer erstellen

Attestierer werden verwendet, um den eigentlichen Signierungsprozess für das Image durchzuführen. Sie fügen dem Image eine Version des Hinweises zur späteren Überprüfung hinzu. Damit Sie Ihren Attestierer verwenden können, müssen Sie den Hinweis auch bei der Binärautorisierung registrieren:

5. Erstellen Sie einen Attestierer:

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

6. Bestätigen Sie den Attestierer:

gcloud container binauthz attestors list

In der letzten Zeile wird NUM_PUBLIC_KEYS: 0 angezeigt. Sie geben die Schlüssel in einem späteren Schritt an.

Cloud Build erstellt automatisch den Attestierer built-by-cloud-build in Ihrem Projekt, wenn Sie einen Build ausführen, der Images generiert. Der obige Befehl gibt also zwei Attestierer zurück: vulnz-attestor und built-by-cloud-build. Nachdem die Images erfolgreich erstellt wurden, signiert Cloud Build automatisch Attestierungen für die Images.

7. Das Dienstkonto der Binärautorisierung benötigt Berechtigungen zum Aufrufen der Attestierung-Hinweise. Gewähren Sie mit dem folgenden API-Aufruf Zugriff auf die IAM-Rolle:

PROJECT_NUMBER=$(gcloud projects describe "${PROJECT_ID}" --format="value(projectNumber)") BINAUTHZ_SA_EMAIL="service-${PROJECT_NUMBER}@gcp-sa-binaryauthorization.iam.gserviceaccount.com" cat > ./iam_request.json << EOM { 'resource': 'projects/${PROJECT_ID}/notes/${NOTE_ID}', 'policy': { 'bindings': [ { 'role': 'roles/containeranalysis.notes.occurrences.viewer', 'members': [ 'serviceAccount:${BINAUTHZ_SA_EMAIL}' ] } ] } } EOM

8. Verwenden Sie die Datei, um die IAM-Richtlinie zu erstellen:

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

Klicken Sie auf Fortschritt prüfen. Erstellen Sie einen Attestierer.

Aufgabe 3: KMS-Schlüssel hinzufügen

Bevor Sie diesen Attestierer verwenden können, muss Ihre Zertifizierungsstelle ein kryptografisches Schlüsselpaar erstellen, mit dem Container-Images signiert werden können. Dies kann über den Google Cloud Key Management Service (KMS) erfolgen.

1. Fügen Sie zuerst einige Umgebungsvariablen hinzu, um den neuen Schlüssel zu beschreiben:

KEY_LOCATION=global KEYRING=binauthz-keys KEY_NAME=codelab-key KEY_VERSION=1

2. Erstellen Sie einen Schlüsselbund, um Schlüssel zu speichern:

gcloud kms keyrings create "${KEYRING}" --location="${KEY_LOCATION}"

3. Erstellen Sie ein neues asymmetrisches Schlüsselpaar für die Signierung für den Attestierer:

gcloud kms keys create "${KEY_NAME}" \ --keyring="${KEYRING}" --location="${KEY_LOCATION}" \ --purpose asymmetric-signing \ --default-algorithm="ec-sign-p256-sha256"

Ihr Schlüssel sollte in der Cloud Console auf der KMS-Seite angezeigt werden.

4. Verknüpfen Sie den Schlüssel nun mit Ihrem Attestierer über den gcloud-Befehl binauthz:

gcloud beta container binauthz attestors public-keys add \ --attestor="${ATTESTOR_ID}" \ --keyversion-project="${PROJECT_ID}" \ --keyversion-location="${KEY_LOCATION}" \ --keyversion-keyring="${KEYRING}" \ --keyversion-key="${KEY_NAME}" \ --keyversion="${KEY_VERSION}"

5. Wenn Sie die Liste der Zertifizierungsstellen noch einmal ausdrucken, sollte jetzt ein registrierter Schlüssel angezeigt werden:

gcloud container binauthz attestors list

Klicken Sie auf Fortschritt prüfen. Fügen Sie einen KMS-Schlüssel hinzu.

Aufgabe 4: Signierte Attestierung erstellen

An diesem Punkt haben Sie die Features konfiguriert, mit denen Sie Images signieren können. Verwenden Sie den zuvor erstellten Attestierer, um das Container-Image zu signieren, mit dem Sie gearbeitet haben.

Eine Attestierung muss eine kryptografische Signatur enthalten, um anzugeben, dass der Attestierer ein bestimmtes Container-Image überprüft hat und es sicher ist, es in Ihrem Cluster auszuführen.

1. Wenn Sie angeben möchten, welches Container-Image bestätigt werden soll, führen Sie den folgenden Befehl aus, um den Digest herauszufinden:

CONTAINER_PATH={{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image DIGEST=$(gcloud container images describe ${CONTAINER_PATH}:latest \ --format='get(image_summary.digest)')

2. Jetzt können Sie mit gcloud Ihre Attestierung erstellen. Der Befehl verwendet die Details des Schlüssels, den Sie zum Signieren verwenden möchten, und das spezifische Container-Image, das Sie genehmigen möchten:

gcloud beta container binauthz attestations sign-and-create \ --artifact-url="${CONTAINER_PATH}@${DIGEST}" \ --attestor="${ATTESTOR_ID}" \ --attestor-project="${PROJECT_ID}" \ --keyversion-project="${PROJECT_ID}" \ --keyversion-location="${KEY_LOCATION}" \ --keyversion-keyring="${KEYRING}" \ --keyversion-key="${KEY_NAME}" \ --keyversion="${KEY_VERSION}"

In Bezug auf Container Analysis wird dadurch ein neuer Hinweis erstellt und an die Notiz des Attestierers angehängt.

3. Führen Sie den folgenden Befehl aus, um Ihre Attestierungen aufzulisten und zu prüfen, ob alles wie erwartet funktioniert hat:

gcloud container binauthz attestations list \ --attestor=$ATTESTOR_ID --attestor-project=${PROJECT_ID}

Aufgabe 5: Richtlinien für die Zugangssteuerung

Die Binärautorisierung ist ein Feature in GKE und Cloud Run, mit dem Regeln validiert werden können, bevor ein Container-Image ausgeführt werden darf. Die Validierung wird bei jeder Anfrage zum Ausführen eines Images ausgeführt, unabhängig davon, ob die Anfrage von einer vertrauenswürdigen CI/CD-Pipeline oder von jemandem stammt, der versucht, ein Image manuell bereitzustellen. So können Sie Ihre Laufzeitumgebungen effektiver schützen als mit CI/CD-Pipeline-Prüfungen allein.

Sie ändern hierfür die Standardrichtlinie für GKE, um eine strenge Autorisierungsregel zu erzwingen.

1. Erstellen Sie GKE-Cluster mit aktivierter Binärautorisierung:

gcloud beta container clusters create binauthz \ --zone {{{ project_0.default_zone | "ZONE" }}} \ --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE

2. Erlauben Sie Cloud Build die Bereitstellung in diesem Cluster:

gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \ --role="roles/container.developer"

„Alle zulassen“-Richtlinie

Prüfen Sie zuerst den Standardrichtlinienstatus und ob Sie ein beliebiges Image bereitstellen können.

1. Prüfen Sie die vorhandene Richtlinie:

gcloud container binauthz policy export

2. Die Richtlinie zur Durchsetzung ist auf ALWAYS_ALLOW festgelegt.

evaluationMode: ALWAYS_ALLOW

3. Stellen Sie ein Beispiel bereit, um zu prüfen, ob Sie etwas bereitstellen können:

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

4. Prüfen Sie, ob die Bereitstellung funktioniert hat:

kubectl get pods

Es wird die folgende Ausgabe angezeigt:

5. Löschen Sie die Bereitstellung:

kubectl delete pod hello-server

„Alle ablehnen“-Richtlinie

Aktualisieren Sie nun die Richtlinie, um keine Images zuzulassen.

1. Exportieren Sie die aktuelle Richtlinie in eine bearbeitbare Datei:

gcloud container binauthz policy export > policy.yaml

2. Öffnen Sie in einem Texteditor die Datei policy.yaml und ändern Sie „evaluationMode“ von ALWAYS_ALLOW in ALWAYS_DENY:

edit policy.yaml

Die bearbeitete YAML-Richtliniendatei sollte so aussehen:

globalPolicyEvaluationMode: ENABLE defaultAdmissionRule: evaluationMode: ALWAYS_DENY enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG name: projects/PROJECT_ID/policy

Diese Richtlinie ist relativ einfach. Die Zeile globalPolicyEvaluationMode deklariert, dass diese Richtlinie die von Google definierte globale Richtlinie erweitert. Dadurch können alle offiziellen GKE-Container standardmäßig ausgeführt werden. Außerdem wird in der Richtlinie eine defaultAdmissionRule deklariert, die angibt, dass alle anderen Pods abgelehnt werden. Die Zulassungsregel enthält die Zeile enforcementMode, die angibt, dass alle Pods, die nicht dieser Regel entsprechen, nicht im Cluster ausgeführt werden dürfen.

Eine Anleitung zum Erstellen komplexerer Richtlinien finden Sie in der Dokumentation zur Binärautorisierung.

3. Führen Sie in Cloud Shell den folgenden Befehl aus, um die neue Richtlinie anzuwenden:

gcloud container binauthz policy import policy.yaml

Warten Sie einige Sekunden, bis die Änderung wirksam wird.

4. Stellen Sie eine Beispielarbeitslast bereit:

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

5. Die Bereitstellung schlägt mit der folgenden Meldung fehl:

Error from server (VIOLATES_POLICY): admission webhook "imagepolicywebhook.image-policy.k8s.io" denied the request: Image gcr.io/google-samples/hello-app:1.0 denied by Binary Authorization default admission rule. Denied by always_deny admission rule

Richtlinie auf „Alle zulassen“ zurücksetzen

Machen Sie die Richtlinienänderungen rückgängig, bevor Sie mit dem nächsten Abschnitt fortfahren.

1. Ändern Sie in einem Texteditor evaluationMode von ALWAYS_DENY in ALWAYS_ALLOW.

edit policy.yaml

Die bearbeitete YAML-Richtliniendatei sollte in etwa so aussehen:

globalPolicyEvaluationMode: ENABLE defaultAdmissionRule: evaluationMode: ALWAYS_ALLOW enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG name: projects/PROJECT_ID/policy

2. Wenden Sie die zurückgesetzte Richtlinie an:

gcloud container binauthz policy import policy.yaml

Klicken Sie auf Fortschritt prüfen. Erstellen Sie ein GKE-Cluster und aktualisieren Sie die Richtlinien.

Aufgabe 6: Images automatisch signieren

Sie haben die Image-Signierung aktiviert und den Attestierer manuell verwendet, um Ihr Beispiel-Image zu signieren. In der Praxis sollten Sie Attestierungen während automatisierter Prozesse wie CI/CD-Pipelines anwenden.

In diesem Abschnitt konfigurieren Sie Cloud Build so, dass Images automatisch bestätigt werden.

Erforderliche Rollen

1. Fügen Sie dem Cloud Build-Dienstkonto die Rolle "Betrachter der Attestierer von Binärautorisierungen" hinzu:

gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \ --role roles/binaryauthorization.attestorsViewer

2. Fügen Sie dem Cloud Build-Dienstkonto (KMS-basierte Signatur) die Rolle "Cloud KMS CryptoKey-Signer/Prüffunktion" hinzu:

gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \ --role roles/cloudkms.signerVerifier gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member serviceAccount:${PROJECT_NUMBER}-compute@developer.gserviceaccount.com \ --role roles/cloudkms.signerVerifier

3. Fügen Sie dem Cloud Build-Dienstkonto die Rolle "Hinzufüger von Container Analysis-Hinweisen" hinzu:

gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \ --role roles/containeranalysis.notes.attacher

Zugriff für Cloud Build-Dienstkonto bereitstellen

Cloud Build benötigt Berechtigungen für den Zugriff auf die On-Demand-Scanning API.

• Gewähren Sie den Zugriff mit den folgenden Befehlen:

gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \ --role="roles/iam.serviceAccountUser" gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \ --role="roles/ondemandscanning.admin"

Benutzerdefinierten Cloud Build-Schritt vorbereiten

Sie verwenden einen benutzerdefinierten Build-Schritt in Cloud Build, um den Attestierungsprozess zu vereinfachen. Dieser Schritt wird von Google bereitgestellt und umfasst Hilfsfunktionen zur Optimierung des Prozesses. Bevor Sie den Schritt verwenden, muss sein Code in einen Container eingebunden und per Push an Cloud Build übertragen werden.

• Führen Sie dazu die folgenden Befehle aus:

git clone https://github.com/GoogleCloudPlatform/cloud-builders-community.git cd cloud-builders-community/binauthz-attestation gcloud builds submit . --config cloudbuild.yaml cd ../.. rm -rf cloud-builders-community

Fügen Sie cloudbuild.yaml einen Signierungsschritt hinzu.

Fügen Sie Ihrer Cloud Build-Pipeline den Attestierungsschritt hinzu.

1. Sehen Sie sich den Signierungsschritt unten an.

Nur überprüfen. Nicht kopieren.

#Sign the image only if the previous severity check passes - id: 'create-attestation' name: 'gcr.io/${PROJECT_ID}/binauthz-attestation:latest' args: - '--artifact-url' - '{{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image' - '--attestor' - 'projects/${PROJECT_ID}/attestors/$ATTESTOR_ID' - '--keyversion' - 'projects/${PROJECT_ID}/locations/$KEY_LOCATION/keyRings/$KEYRING/cryptoKeys/$KEY_NAME/cryptoKeyVersions/$KEY_VERSION'

2. Schreiben Sie eine cloudbuild.yaml-Datei mit der vollständigen Pipeline unten:

cat > ./cloudbuild.yaml << EOF steps: # build - id: "build" name: 'gcr.io/cloud-builders/docker' args: ['build', '-t', '{{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image', '.'] waitFor: ['-'] # additional CICD checks (not shown) #Retag - id: "retag" name: 'gcr.io/cloud-builders/docker' args: ['tag', '{{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image', '{{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good'] #pushing to artifact registry - id: "push" name: 'gcr.io/cloud-builders/docker' args: ['push', '{{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good'] #Sign the image only if the previous severity check passes - id: 'create-attestation' name: 'gcr.io/${PROJECT_ID}/binauthz-attestation:latest' args: - '--artifact-url' - '{{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good' - '--attestor' - 'projects/${PROJECT_ID}/attestors/$ATTESTOR_ID' - '--keyversion' - 'projects/${PROJECT_ID}/locations/$KEY_LOCATION/keyRings/$KEYRING/cryptoKeys/$KEY_NAME/cryptoKeyVersions/$KEY_VERSION' images: - {{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good EOF

3. Führen Sie den Build aus:

gcloud builds submit

Überprüfen Sie den Build im Cloud Build-Verlauf:

Rufen Sie in der Cloud Console die Seite Cloud Build > Build-Verlauf auf und prüfen Sie den letzten Build und die erfolgreiche Ausführung der Build-Schritte.

Klicken Sie auf Fortschritt prüfen. Fügen Sie einen Signierungsschritt hinzu.

Aufgabe 7: Signierte Images autorisieren

Jetzt aktualisieren Sie GKE, um mit der Binärautorisierung zu prüfen, ob das Image eine Signatur vom Scannen auf Sicherheitslücken hat, bevor das Image ausgeführt werden darf.

GKE-Richtlinie auf „require“-Attestierung aktualisieren

„require“-Images werden von Ihrem Attestor signiert, indem Sie Ihrer GKE BinAuth-Richtlinie „clusterAdmissionRules“ hinzufügen.

Derzeit wird in Ihrem Cluster eine Richtlinie mit einer Regel ausgeführt: Container aus offiziellen Repositories zulassen und alle anderen ablehnen.

1. Überschreiben Sie die Richtlinie mit der aktualisierten Konfiguration, indem Sie den folgenden Befehl ausführen:

COMPUTE_ZONE={{{ project_0.default_region | "REGION" }}} cat > binauth_policy.yaml << EOM defaultAdmissionRule: enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG evaluationMode: REQUIRE_ATTESTATION requireAttestationsBy: - projects/${PROJECT_ID}/attestors/vulnz-attestor globalPolicyEvaluationMode: ENABLE clusterAdmissionRules: ${COMPUTE_ZONE}.binauthz: evaluationMode: REQUIRE_ATTESTATION enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG requireAttestationsBy: - projects/${PROJECT_ID}/attestors/vulnz-attestor EOM

2. Sie sollten jetzt die neue Datei updated_policy.yaml auf dem Laufwerk haben. Anstatt alle Images standardmäßig abzulehnen, wird jetzt zuerst Ihr Attestierer auf Bestätigungen geprüft.

3. Laden Sie die neue Richtlinie in die Binärautorisierung hoch:

gcloud beta container binauthz policy import binauth_policy.yaml

Signiertes Image bereitstellen

1. Rufen Sie den Image-Digest für das gutes Image ab:

CONTAINER_PATH={{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image DIGEST=$(gcloud container images describe ${CONTAINER_PATH}:good \ --format='get(image_summary.digest)')

2. Verwenden Sie den Digest in der Kubernetes-Konfiguration:

cat > deploy.yaml << EOM apiVersion: v1 kind: Service metadata: name: deb-httpd spec: selector: app: deb-httpd ports: - protocol: TCP port: 80 targetPort: 8080 --- apiVersion: apps/v1 kind: Deployment metadata: name: deb-httpd spec: replicas: 1 selector: matchLabels: app: deb-httpd template: metadata: labels: app: deb-httpd spec: containers: - name: deb-httpd image: ${CONTAINER_PATH}@${DIGEST} ports: - containerPort: 8080 env: - name: PORT value: "8080" EOM

3. Stellen Sie die Anwendung in GKE bereit:

kubectl apply -f deploy.yaml

Rufen Sie in der Cloud Console Kubernetes Engine > Arbeitslasten auf und prüfen Sie, ob das Image bereitgestellt wurde.

Klicken Sie auf Fortschritt prüfen. Stellen Sie ein signiertes Image bereit.

Aufgabe 8: Blockierte unsignierte Images

Image erstellen

1. Verwenden Sie das lokale Docker, um das Image in Ihrem lokalen Cache zu erstellen:

docker build -t {{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:bad .

2. Übertragen Sie das nicht signierte Image per Push in das Repository:

docker push {{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:bad

3. Rufen Sie den Image-Digest für das fehlerhafte Image ab:

CONTAINER_PATH={{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image DIGEST=$(gcloud container images describe ${CONTAINER_PATH}:bad \ --format='get(image_summary.digest)')

4. Verwenden Sie den Digest in der Kubernetes-Konfiguration:

cat > deploy.yaml << EOM apiVersion: v1 kind: Service metadata: name: deb-httpd spec: selector: app: deb-httpd ports: - protocol: TCP port: 80 targetPort: 8080 --- apiVersion: apps/v1 kind: Deployment metadata: name: deb-httpd spec: replicas: 1 selector: matchLabels: app: deb-httpd template: metadata: labels: app: deb-httpd spec: containers: - name: deb-httpd image: ${CONTAINER_PATH}@${DIGEST} ports: - containerPort: 8080 env: - name: PORT value: "8080" EOM

5. Versuchen Sie, die Anwendung in GKE bereitzustellen:

kubectl apply -f deploy.yaml

Sehen Sie sich die Arbeitslast in der Console an und notieren Sie sich den Fehler, der angibt, dass die Bereitstellung abgelehnt wurde:

No attestations found that were valid and signed by a key trusted by the attestor

Klicken Sie auf Fortschritt prüfen. Stellen Sie ein nicht signiertes Image bereit.

Glückwunsch!

Sie haben gelernt, wie Sie einen Attestierer erstellen, um Images zu signieren und Regeln zu validieren, bevor ein Container-Image ausgeführt werden darf. Sie haben gelernt, wie Sie eine Richtlinie schreiben, um Cloud Build mitzuteilen, ob der Zugriff auf den GKE-Cluster zulässig ist oder nicht. Außerdem haben Sie die Binärautorisierung mit Google Cloud KMS verwendet, um Image-Signaturen zu validieren und zu verhindern, dass nicht signierte Images auf den Kubernetes-Cluster zugreifen.

Weitere Informationen

• Bereitstellung von Images in Cloud Run und Google Kubernetes Engine schützen | Cloud Build-Dokumentation
• Kurzanleitung: Richtlinie zur Binärautorisierung mit GKE konfigurieren | Google Cloud

Google Cloud-Schulungen und ‑Zertifizierungen

In unseren Schulungen erfahren Sie alles zum optimalen Einsatz unserer Google Cloud-Technologien und können sich entsprechend zertifizieren lassen. Unsere Kurse vermitteln technische Fähigkeiten und Best Practices, damit Sie möglichst schnell mit Google Cloud loslegen und Ihr Wissen fortlaufend erweitern können. Wir bieten On-Demand-, Präsenz- und virtuelle Schulungen für Anfänger wie Fortgeschrittene an, die Sie individuell in Ihrem eigenen Zeitplan absolvieren können. Mit unseren Zertifizierungen weisen Sie nach, dass Sie Experte im Bereich Google Cloud-Technologien sind.

Anleitung zuletzt aktualisiert am 10. September 2024

Lab zuletzt am 2. Juli 2024 getestet

© 2024 Google LLC. Alle Rechte vorbehalten. Google und das Google-Logo sind Marken von Google LLC. Alle anderen Unternehmens- und Produktnamen können Marken der jeweils mit ihnen verbundenen Unternehmen sein.