Erste Schritte mit der Google Cloud Console (GKE)


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:

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

Hinweis

  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. Container Registry, Artifact Analysis and Binary Authorization APIs aktivieren.

    Aktivieren Sie die APIs

  5. Installieren Sie die Google Cloud CLI.
  6. Führen Sie folgenden Befehl aus, um die gcloud CLI zu initialisieren:

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

    Zur Projektauswahl

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

  9. Container Registry, Artifact Analysis and Binary Authorization APIs aktivieren.

    Aktivieren Sie die APIs

  10. Installieren Sie die Google Cloud CLI.
  11. Führen Sie folgenden Befehl aus, um die gcloud CLI zu initialisieren:

    gcloud init
  12. 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:

  1. Rufen Sie in der Google Cloud Console das GKE-Menü auf.

    Zu GKE

  2. Klicken Sie auf Cluster erstellen.

  3. Geben Sie in das Feld Name test-cluster ein.

  4. Wählen Sie unter Standorttyp die Option Zonal aus.

  5. Wählen Sie aus der Drop-down-Liste Zone us-central1-a aus.

  6. Klicken Sie auf Verfügbarkeit, Netzwerk, Sicherheit und weitere Features.

  7. Wählen Sie im Abschnitt Sicherheit die Option Binärautorisierung aktivieren aus.

  8. Wählen Sie Nur erzwingen aus.

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

  1. Rufen Sie in der Google Cloud Console die Seite "Binärautorisierung" auf.

    Zur Binärautorisierung

  2. Klicken Sie auf Richtlinie bearbeiten.

  3. Unter Projektstandardregel wird die Option Alle Images zulassen angezeigt.

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

  1. Erstellen Sie den privaten Schlüssel:

    PRIVATE_KEY_FILE="/tmp/ec_private.pem"
    openssl ecparam -genkey -name prime256v1 -noout -out ${PRIVATE_KEY_FILE}
    
  2. 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:

  1. Kehren Sie zur Seite der Binärautorisierung in der Google Cloud Console zurück.

    Kehren Sie zur Binärautorisierung zurück

  2. Klicken Sie im Tab Attestierer auf Erstellen.

    Screenshot des Tabs mit der Standardregel

  3. Füllen Sie die Felder so aus:

    1. Geben Sie in das Feld Name des Attestierers test-attestor ein.

    2. Prüfen Sie, ob das Kästchen Artefaktanalyse-Hinweis automatisch erstellen angeklickt ist.

    3. Klicken Sie auf Öffentlichen PKIX-Schlüssel hinzufügen.

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

    5. Klicken Sie im Drop-down-Menü Signaturalgorithmus auf Elliptic Curve P-256 - SHA256 Digest.

    6. Klicken Sie auf Fertig.

  4. Klicken Sie auf Erstellen, um den Attestierer zu erstellen.

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

  1. Kehren Sie in der Google Cloud Console zur Seite der Binärautorisierung zurück.

  2. Im Tab Richtlinie klicken Sie auf Richtlinie bearbeiten.

  3. Wählen Sie Nur Images zulassen, die von allen folgenden Attestierern genehmigt wurden aus.

  4. Klicken Sie auf Attestierer hinzufügen.

  5. Klicken Sie auf Basierend auf dem Projekt und Attestierernamen hinzufügen.

  6. Geben Sie in das Feld Projektname PROJECT_ID ein.

  7. Geben Sie in das Feld Name des Attestierers test-attestor ein.

  8. Klicken Sie auf 1 Attestierer hinzufügen.

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

  1. 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}
    
  2. 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"
    }
    }
    
  3. 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.

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

  5. Prüfen Sie, ob die Attestierung erstellt wurde:

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

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

Richtlinie noch einmal testen

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

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