Erste Schritte mit der Befehlszeile

In diesem Leitfaden wird beschrieben, wie Sie eine Richtlinie für Binärautorisierungen konfigurieren und testen, die Attestierungen erfordert. Mit diesem Richtlinientyp wird die Container-basierte Softwarelieferkette gesichert. In der Richtlinie wird definiert, 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 die Aufgaben beschrieben, die Sie über die Befehlszeile ausführen. Wie Sie diese Schritte mit der Google Cloud Console ausführen, erfahren Sie unter Erste Schritte mit der Console.

Ziele

In dieser Anleitung erfahren Sie mehr über die folgenden Themen:

  • Google Kubernetes Engine-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 dieser Anleitung werden kostenpflichtige Komponenten von Google Cloud verwendet, darunter:

  • Container Registry
  • GKE

Mit dem Preisrechner können Sie anhand Ihrer voraussichtlichen Nutzung eine Kostenschätzung generieren. Neuen Cloud Platform-Nutzern steht möglicherweise eine kostenlose Testversion zur Verfügung.

Vorbereitung

  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 Cloud-Projekt muss aktiviert sein. So prüfen Sie, ob die Abrechnung für Ihr Projekt aktiviert ist.

  4. Installieren und initialisieren Sie das Cloud SDK.
  5. Installieren Sie kubectl für die Interaktion mit GKE.

Binärautorisierung aktivieren

Standardprojekt festlegen

Im ersten Schritt legen Sie das Google Cloud-Standardprojekt fest, das vom gcloud-Befehl verwendet werden soll.

PROJECT_ID=PROJECT_ID
gcloud config set project ${PROJECT_ID}

Dabei ist PROJECT_ID der Name Ihres Projekts.

Erforderliche APIs aktivieren

Aktivieren Sie als Nächstes die Google Cloud APIs für GKE, Container Analysis und die Binärautorisierung:

gcloud services enable \
    container.googleapis.com \
    containeranalysis.googleapis.com \
    binaryauthorization.googleapis.com

Cluster mit aktivierter Binärautorisierung erstellen

Cluster erstellen

Nun können Sie einen GKE-Cluster mit aktivierter Binärautorisierung erstellen. Dies ist der Cluster, in dem die bereitgestellten Container-Images ausgeführt werden sollen. Wenn Sie den Cluster erstellen, übergeben Sie das Flag --enable-binauthz an den Befehl gcloud container clusters create.

So erstellen Sie den Cluster:

gcloud container clusters create \
    --enable-binauthz \
    --zone us-central1-a \
    test-cluster

Hier erstellen Sie einen Cluster mit dem Namen test-cluster in der GKE-Zone us-central1-a.

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.

Mit der Binärautorisierung können Sie eine Richtliniendatei im YAML-Format exportieren und importieren. Dieses Format spiegelt die Struktur einer Richtlinie wider, wie sie vom Dienst gespeichert wird. Wenn Sie eine Richtlinie mit gcloud-Befehlen konfigurieren, bearbeiten Sie diese Datei.

Um die Standardrichtlinie aufzurufen, exportieren Sie die YAML-Richtliniendatei:

gcloud container binauthz policy export

Die Datei hat standardmäßig folgenden Inhalt:

admissionWhitelistPatterns:
- namePattern: gcr.io/google_containers/*
- namePattern: gcr.io/google-containers/*
- namePattern: k8s.gcr.io/*
- namePattern: gke.gcr.io/*
- namePattern: gcr.io/stackdriver-agents/*
globalPolicyEvaluationMode: ENABLE
defaultAdmissionRule:
  evaluationMode: ALWAYS_ALLOW
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
name: projects/${PROJECT_ID}/policy

Hier wird die Standardregel im Knoten defaultAdmissionRule definiert. evaluationMode gibt an, dass die Richtlinie alle Image-Deployments zulässt.

Weitere Informationen zur Struktur einer Richtlinie finden Sie in der Referenz zu YAML-Richtlinien.

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 in der Regel von Personal Ihrer Organisation verwaltet, das für die Sicherheit der Softwarelieferkette verantwortlich ist.

So erstellen Sie einen Attestierer:

  • Erstellen Sie in Container Analysis einen Hinweis, um vertrauenswürdige Metadaten zu speichern, die während des Autorisierungsvorgangs verwendet werden.
  • Erstellen Sie den Attestierer selbst in der Binärautorisierung und verknüpfen Sie den zuvor erstellten Hinweis.

In dieser Anleitung haben Sie einen Attestierer namens test-attestor und einen Container Analysis-Hinweis mit dem Namen test-attestor-note. In der Praxis können Sie eine beliebige Anzahl von Attestierern haben. Dabei repräsentiert jeder Attestierer eine Partei, die am Autorisierungsprozess für ein Container-Image beteiligt ist.

Container Analysis-Hinweis erstellen

  1. Legen Sie Variablen fest, in denen der Name des Attestierers und der Container Analysis-Hinweis gespeichert sind:

    ATTESTOR=test-attestor
    NOTE_ID=test-attestor-note
    
  2. Erstellen Sie in /tmp/note_payload.json eine JSON-Datei, die den Container Analysis-Hinweis beschreibt:

    cat > /tmp/note_payload.json << EOM
    {
      "name": "projects/${PROJECT_ID}/notes/${NOTE_ID}",
      "attestation": {
        "hint": {
          "human_readable_name": "Attestor Note"
        }
      }
    }
    EOM
    
  3. Erstellen Sie den Hinweis, indem Sie eine HTTP-Anfrage an die Container Analysis REST API senden:

    curl -X POST \
        -H "Content-Type: application/json" \
        -H "Authorization: Bearer $(gcloud auth print-access-token)"  \
        --data-binary @/tmp/note_payload.json  \
        "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/?noteId=${NOTE_ID}"
    
  4. Prüfen Sie, ob der Hinweis erstellt wurde:

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

Attestierer erstellen

Jetzt können Sie den Attestierer erstellen:

  1. Erstellen Sie den Attestierer in der Binärautorisierung:

    gcloud container binauthz attestors create ${ATTESTOR} \
    --attestation-authority-note=${NOTE_ID} \
    --attestation-authority-note-project=${PROJECT_ID}
    
  2. Prüfen Sie, ob der Attestierer erstellt wurde:

    gcloud container binauthz attestors list
    

Der von Ihnen erstellte Attestierer kann jetzt noch nicht verwendet werden. Es fehlt noch ein verknüpftes PKIX-Schlüsselpaar, das Sie unten erstellen.

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 Signaturalgorithmen 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}
    
  3. Fügen Sie den öffentlichen ECDSA-Schlüssel dem Attestierer hinzu.

    Fügen Sie nun den öffentlichen Schlüssel hinzu, den Sie in den Attestierer exportiert haben, damit er von der Binärautorisierung für die Identitätsprüfung verwendet werden kann:

    gcloud --project="${PROJECT_ID}" \
        beta container binauthz attestors public-keys add \
        --attestor="${ATTESTOR}" \
        --pkix-public-key-file=${PUBLIC_KEY_FILE} \
        --pkix-public-key-algorithm=ecdsa-p256-sha256
    
  4. Speichern Sie die ID des öffentlichen Schlüssels.

    Zum Speichern der öffentlichen Schlüssel-ID können Sie diese aus der Ausgabe von public-keys add oben kopieren. 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}

    PUBLIC_KEY_ID=$(gcloud container binauthz attestors describe ${ATTESTOR} \
      --format='value(userOwnedGrafeasNote.publicKeys[0].id)')
    

Richtlinie konfigurieren

Jetzt können Sie Ihre Richtlinie konfigurieren: In diesem Schritt exportieren Sie die YAML-Richtliniendatei in Ihr lokales System. Dort ändern Sie die Standardregel so, dass sie eine Attestierung durch den Attestierer erfordert, den Sie oben definiert haben.

So konfigurieren Sie die Richtlinie:

  1. Erstellen Sie eine neue Richtliniendatei, die von Google verwaltete Systemimages zulässt, evaluationMode auf REQUIRE_ATTESTATION setzt und einen Knoten mit dem Namen requireAttestationsBy hinzufügt, der auf den von Ihnen erstellten Attestierer verweist:

    cat > /tmp/policy.yaml << EOM
        globalPolicyEvaluationMode: ENABLE
        defaultAdmissionRule:
          evaluationMode: REQUIRE_ATTESTATION
          enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
          requireAttestationsBy:
            - projects/${PROJECT_ID}/attestors/${ATTESTOR}
        name: projects/${PROJECT_ID}/policy
    EOM
    
  2. Importieren Sie die YAML-Richtliniendatei in die Binärautorisierung:

    gcloud container binauthz policy import /tmp/policy.yaml
    

Weitere Informationen zum Konfigurieren einer Richtlinie finden Sie unter Richtlinie über die Befehlszeile 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 das Beispiel-Image verwenden, das sich in Container Registry unter dem Pfad gcr.io/google-samples/hello-app befindet. Dies ist ein von Google erstelltes öffentliches Container-Image, das die Hello-World-Beispielanwendung enthält.

Versuchen Sie zuerst, das Image bereitzustellen:

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

Prüfen Sie nun, 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}}'

Dies zeigt, dass das Deployment von der Richtlinie nicht zugelassen wurde:

FailedCreate: Error creating: pods "hello-server-579859fb5b-hjvnr" is forbidden: image policy webhook backend denied one or more images: Denied by default admission rule. Denied by Attestation Authority. Image gcr.io/google-samples/hello-app:1.0 denied by projects/example-project/attestors/test-attestor: No attestations found

Das Deployment muss gelöscht werden, damit Sie mit dem nächsten Schritt fortfahren können:

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. Ein Signer kann eine Person sein, ist aber meistens ein automatisierter Prozess, der beim Erstellen eines Container-Images ausgeführt wird. Die Signatur wird mit dem privaten Schlüssel aus einem Schlüsselpaar erstellt. Beim Deployment prüft der Binärautorisierungserzwinger mit dem öffentlichen Schlüssel des Attestierers die Signatur in der Attestierung.

In dieser Anleitung wird in der Attestierung einfach angegeben, dass Sie das Image für das Deployment autorisieren.

So erstellen Sie eine Attestierung:

  1. Legen Sie Variablen fest, die den Registry-Pfad und den Digest des Images speichern:

    IMAGE_PATH="gcr.io/google-samples/hello-app"
    IMAGE_DIGEST="sha256:c62ead5b8c15c231f9e786250b07909daf6c266d0fcddd93fea882eb722c3be4"
    
  2. Erstellen Sie die Attestierungsnutzlast:

    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"
      }
    }
    
  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 Sie die Attestierung:

    gcloud container binauthz attestations create \
        --artifact-url="${IMAGE_PATH}@${IMAGE_DIGEST}" \
        --attestor="projects/${PROJECT_ID}/attestors/${ATTESTOR}" \
        --signature-file=/tmp/ec_signature \
        --public-key-id="${PUBLIC_KEY_ID}"
    

    Alternativ können Sie Folgendes eingeben, um die Attestierung zu erstellen und zu bestätigen, dass sie vom bereitgestellten Attestierer geprüft werden kann:

    gcloud alpha container binauthz attestations create \
        --artifact-url="${IMAGE_PATH}@${IMAGE_DIGEST}" \
        --attestor="projects/${PROJECT_ID}/attestors/${ATTESTOR}" \
        --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.

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

    gcloud container binauthz attestations list \
        --attestor=$ATTESTOR --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.

So stellen Sie das Image bereit:

kubectl run hello-server --image ${IMAGE_PATH}@${IMAGE_DIGEST} --port 8080

So prüfen Sie, ob das Image bereitgestellt wurde:

kubectl get pods

Der Befehl gibt eine Nachricht ähnlich der folgenden aus, die angibt, dass das Deployment erfolgreich war:

NAME                            READY     STATUS    RESTARTS   AGE
hello-server-579859fb5b-h2k8s   1/1       Running   0          1m

Bereinigen

So vermeiden Sie, dass Ihrem Google Cloud Platform-Konto die in dieser Anleitung verwendeten Ressourcen in Rechnung gestellt werden:

Löschen Sie den in GKE erstellten Cluster:

gcloud container clusters delete \
    --zone=us-central1-a \
    test-cluster

Nächste Schritte