Einrichtung von mehreren Projekten konfigurieren

---

In dieser Anleitung wird beschrieben, wie Sie die Binärautorisierung in einer Konfiguration mit mehreren Projekten verwenden. Eine einfachere Konfiguration für ein einzelnes Projekt finden Sie unter Erste Schritte mit der Google Cloud CLI (GKE).

Zum Einrichten der Aufgabentrennung können Sie die Binärautorisierung in einer Konfiguration mit mehreren Projekten einrichten. Der Zweck jedes Projekts wird weiter unten in dieser Anleitung erläutert.

Ziele

In dieser Anleitung führen Sie die folgenden Aufgaben aus:

1. Richten Sie ein anderes Projekt für die Bereitstellung (GKE), den Attestierer und die Attestierungsverwaltung ein, um die Aufgabentrennung zu unterstützen.

2. Konfigurieren Sie die Standardregel Ihrer Richtlinie für die Binärautorisierung so, dass Attestierungen erforderlich sind.

3. Erstellen Sie ein Schlüsselpaar, das signiert werden soll, und prüfen Sie später die Attestierung.

4. Erstellen Sie einen Attestierer, mit dem die Binärautorisierungserzwingung die Attestierung prüft.

5. Beispielbild erstellen, um eine Attestierung zu erstellen

6. Testen Sie die Richtlinie, indem Sie das Beispiel-Image bereitstellen.

Sie müssen die entsprechende Zugriffssteuerung jedes Projekts über Identity and Access Management (IAM) konfigurieren.

Für zusätzliche Sicherheit können Sie VPC Service Controls verwenden, um die in dieser Anleitung erstellten Ressourcen noch besser zu schützen. Weitere Informationen finden Sie unter Mit VPC Service Controls sichern.

Kosten

In diesem Dokument verwenden Sie die folgenden kostenpflichtigen Komponenten von Google Cloud:

• Artifact Registry oder Container Registry
• Binärautorisierung
• GKE
• Container Registry
• Optional: Cloud Key Management Service

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

Hinweis: Für diese Konfiguration richten Sie drei Projekte ein.

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.

   Hinweis: Wenn Sie die Ressourcen, die Sie in diesem Verfahren erstellen, nicht behalten möchten, erstellen Sie ein Projekt, anstatt ein vorhandenes Projekt auszuwählen. Wenn Sie fertig sind, können Sie das Projekt löschen und dadurch alle mit dem Projekt verknüpften Ressourcen entfernen.

   Zur Projektauswahl

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

4. Installieren Sie die Google Cloud CLI.

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

   gcloud init

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

   Hinweis: Wenn Sie die Ressourcen, die Sie in diesem Verfahren erstellen, nicht behalten möchten, erstellen Sie ein Projekt, anstatt ein vorhandenes Projekt auszuwählen. Wenn Sie fertig sind, können Sie das Projekt löschen und dadurch alle mit dem Projekt verknüpften Ressourcen entfernen.

   Zur Projektauswahl

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

8. Installieren Sie die Google Cloud CLI.

9. Führen Sie folgenden Befehl aus, um die gcloud CLI zu initialisieren:

   gcloud init

10. Installieren Sie kubectl für die Interaktion mit GKE.

Deployer-Projekt einrichten

Das Deployer-Projekt verwaltet die Google Kubernetes Engine-Cluster (GKE), in denen Sie Images bereitstellen, und die Binärautorisierungsrichtlinie, die von der Binärautorisierung zum Zeitpunkt der Bereitstellung erzwungen wird. Je nach Größe, Komplexität und anderen Anforderungen Ihrer Umgebung können Sie mehr als ein Deployer-Projekt haben.

Hinweis: Wenn Sie denselben Attestierer in mehreren Deployer-Projekten verwenden möchten, wiederholen Sie die Schritte unten und ersetzen Sie DEPLOYER_PROJECT_ID durch die ID der jeweiligen Deployer-Projekte.

So richten Sie das Deployer-Projekt ein:

1. Erstellen Sie das Projekt in der Google Cloud Console und aktivieren Sie die Abrechnung, falls Sie dies noch nicht getan haben.

2. Hinweis zur Identitäts- und Zugriffsverwaltung: Das Deployer-Projekt enthält Ihren GKE-Cluster. Dies sollte in der Konfiguration der Identitäts- und Zugriffsverwaltung für dieses Projekt widergespiegelt werden.

3. Legen Sie Umgebungsvariablen zum Speichern des Google Cloud-Projekts und der Nummer fest:

   DEPLOYER_PROJECT_ID=DEPLOYER_PROJECT_ID
   

   Ersetzen Sie DEPLOYER_PROJECT_ID durch die Google Cloud-Projekt-ID.

   DEPLOYER_PROJECT_NUMBER=$(gcloud projects describe "${DEPLOYER_PROJECT_ID}" \
       --format="value(projectNumber)")
   

4. APIs aktivieren:

   Container Registry

   gcloud --project=${DEPLOYER_PROJECT_ID} \
     services enable\
     container.googleapis.com\
     containerregistry.googleapis.com\
     binaryauthorization.googleapis.com
   

   Artifact Registry

   gcloud --project=${DEPLOYER_PROJECT_ID} \
     services enable\
     container.googleapis.com\
     artifactregistry.googleapis.com\
     binaryauthorization.googleapis.com
   

5. Rufen Sie den Namen des Dienstkontos des Deployer-Projekts ab:

   DEPLOYER_SERVICE_ACCOUNT="service-${DEPLOYER_PROJECT_NUMBER}@gcp-sa-binaryauthorization.iam.gserviceaccount.com"
   

   Sie benötigen den Namen des Dienstkontos in einem späteren Schritt, wenn Sie Berechtigungen für den mit Ihrem Attestierer verknüpften Artefaktanalyse-Hinweis konfigurieren.

Attestiererprojekt einrichten

Ein Attestiererprojekt speichert die Attestierer, die prüfen, ob ein Image für das Deployment bereit ist. Häufig haben Sie nur ein Attestiererprojekt, das als zentraler Speicher für Informationen zu vertrauenswürdigen Parteien im Autorisierungsprozess dient. Auf diese Weise können Sie Sicherheitsschlüssel, die zur Prüfung der Identität von Attestierern erforderlich sind, zentral verwalten und den Zugriff auf diejenigen Personen beschränken, die sie verwalten.

So richten Sie das Attestiererprojekt ein:

1. Erstellen Sie das Projekt in der Google Cloud Console und aktivieren Sie die Abrechnung, falls Sie dies noch nicht getan haben.

2. Hinweis zur Identitäts- und Zugriffsverwaltung: Da dieses Projekt Ihre Attestierer enthält, sollte nur Sicherheitspersonal Schreibzugriff haben.

3. Legen Sie Umgebungsvariablen zum Speichern des Projektnamens und der Projektnummer fest:

   ATTESTOR_PROJECT_ID=ATTESTOR_PROJECT_ID
   

   Ersetzen Sie ATTESTOR_PROJECT_ID durch die ID des Attestiererprojekts.

   ATTESTOR_PROJECT_NUMBER=$(gcloud projects describe "${ATTESTOR_PROJECT_ID}" \
       --format="value(projectNumber)")
   

4. Aktivieren Sie die Artifact Analysis API und die Binary Authorization API:

   gcloud services --project=${ATTESTOR_PROJECT_ID} \
       enable containeranalysis.googleapis.com \
       binaryauthorization.googleapis.com
   

5. Rufen Sie den Namen des Dienstkontos des Attestiererprojekts ab:

   ATTESTOR_SERVICE_ACCOUNT="service-${ATTESTOR_PROJECT_NUMBER}@gcp-sa-binaryauthorization.iam.gserviceaccount.com"
   

   Sie benötigen den Namen des Dienstkontos in einem späteren Schritt, wenn Sie Berechtigungen für den mit Ihrem Attestierer verknüpften Artefaktanalyse-Hinweis konfigurieren.

Attestierungsprojekt einrichten

Im Attestierungsprojekt werden die Attestierungen gespeichert, die von den Attestierern bei der Prüfung eines Images erstellt werden. Mit einem separaten Attestierungsprojekt können Sie Anweisungen zur Softwarebereitschaft einfacher organisieren und prüfen.

1. Erstellen Sie das Projekt in der Google Cloud Console und aktivieren Sie die Abrechnung, falls Sie dies noch nicht getan haben.

2. Hinweis zur Identitäts- und Zugriffsverwaltung: Alle Rollen, die an der Binärautorisierung beteiligt sind, sollten Lesezugriff auf die Artefaktanalyse-Hinweise und -Instanzen in diesem Projekt haben. Schreibzugriff hingegen benötigen nur Attestierungsmanager.

3. Legen Sie eine Umgebungsvariable zum Speichern des Projektnamens fest:

   ATTESTATION_PROJECT_ID=ATTESTATION_PROJECT_ID
   

   Ersetzen Sie ATTESTATION_PROJECT_ID durch die Attestierungsprojekt-ID.

4. Aktivieren Sie die Artifact Analysis API und die Binary Authorization API:

   gcloud services --project=${ATTESTATION_PROJECT_ID} \
       enable containeranalysis.googleapis.com \
       binaryauthorization.googleapis.com
   

Cluster erstellen

Jetzt können Sie im Deployer-Projekt einen GKE-Cluster erstellen. Dies ist der Cluster, in dem die bereitgestellten Container-Images ausgeführt werden sollen. Wenn Sie den Cluster erstellen, übergeben Sie das Flag --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE an den Befehl gcloud container clusters create.

So erstellen Sie den Cluster:

gcloud --project=${DEPLOYER_PROJECT_ID} \
    container clusters create \
    --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE \
    --zone us-central1-a \
    test-cluster

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

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 --project=${DEPLOYER_PROJECT_ID} \
    container clusters get-credentials \
    --zone us-central1-a \
    test-cluster

Attestierer erstellen

Ein Attestierer bestätigt, dass ein erforderlicher Prozess abgeschlossen wurde, bevor ein Container-Image bereitgestellt werden kann. Diese Partei kann ein menschlicher Nutzer sein, ist aber häufiger ein maschineller Prozess, wie ein Build- und Testsystem oder Ihre Pipelines für Continuous Integration (CI) und Continuous Deployment (CD). Sie erstellen die Attestierer in Ihrem Attestiererprojekt.

So erstellen Sie einen Attestierer:

• Erstellen Sie in Artefaktanalyse einen Hinweis, um vertrauenswürdige Metadaten zu speichern, die während des Autorisierungsvorgangs verwendet werden.
• Erstellen Sie im Attestiererprojekt den Attestierer selbst und verknüpfen Sie den zuvor erstellten Hinweis.
• Fügen Sie dem Attestierer eine IAM-Rollenbindung für das Dienstkonto des Deployer-Projekts hinzu.
• Berechtigungen für den Artefaktanalyse-Hinweis festlegen

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 das Image beteiligt ist.

Artefaktanalyse-Hinweis erstellen

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

   ATTESTOR_NAME=test-attestor
   NOTE_ID=test-attestor-note
   

   Ersetzen Sie:

   • test-attestor: der Name des Attestierers Ihrer Wahl
   • test-attestor-note: der Hinweisname des Attestierers Ihrer Wahl

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/${ATTESTOR_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 Artifact 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/${ATTESTOR_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/${ATTESTOR_PROJECT_ID}/notes/${NOTE_ID}"
   

Attestierer erstellen

Jetzt können Sie den Attestierer erstellen:

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

   gcloud --project=${ATTESTOR_PROJECT_ID} \
       container binauthz attestors create ${ATTESTOR_NAME} \
       --attestation-authority-note=${NOTE_ID} \
       --attestation-authority-note-project=${ATTESTOR_PROJECT_ID}
   

2. Prüfen Sie, ob der Attestierer erstellt wurde:

   gcloud --project=${ATTESTOR_PROJECT_ID} \
       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.

IAM-Rollenbindung für das Deployer-Projekt hinzufügen

Sie müssen dem Attestierer eine IAM-Rollenbindung für das Deployer-Projekt hinzufügen. Diese wird von der Binärautorisierung bei der Prüfung einer Richtlinie verwendet, um festzustellen, ob das Projekt berechtigt ist, auf zugehörige Attestierungen zuzugreifen.

So fügen Sie die IAM-Rollenbindung hinzu:

gcloud --project ${ATTESTOR_PROJECT_ID} \
    container binauthz attestors add-iam-policy-binding \
    "projects/${ATTESTOR_PROJECT_ID}/attestors/${ATTESTOR_NAME}" \
    --member="serviceAccount:${DEPLOYER_SERVICE_ACCOUNT}" \
    --role=roles/binaryauthorization.attestorsVerifier

Berechtigungen für den Artefaktanalyse-Hinweis festlegen

Sie müssen auch Berechtigungen für den von Ihnen erstellten Artefaktanalyse-Hinweis festlegen, sodass er sowohl für das Deployer-Projekt als auch für das Attestierer-Projekt zugänglich ist. Aktualisieren Sie dazu die IAM-Richtlinie für den Hinweis so, dass die Projektdienstkonten Betrachter-Zugriff erhalten.

1. Erstellen Sie eine JSON-Datei mit den erforderlichen Informationen, um die IAM-Richtlinie für den Hinweis festzulegen:

   cat > /tmp/iam_request.json << EOM
   {
     'resource': 'projects/${ATTESTOR_PROJECT_ID}/notes/${NOTE_ID}',
     'policy': {
       'bindings': [
         {
           'role': 'roles/containeranalysis.notes.occurrences.viewer',
           'members': [
             'serviceAccount:${ATTESTOR_SERVICE_ACCOUNT}',
             'serviceAccount:${DEPLOYER_SERVICE_ACCOUNT}'
           ]
         }
       ]
     }
   }
   EOM
   

2. Fügen Sie der IAM-Richtlinie für den von Ihnen erstellten Hinweis das Dienstkonto und die angeforderten Zugriffsrollen hinzu:

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

PKIX-Schlüssel einrichten

Die Binärautorisierung verwendet kryptografische Schlüssel, um die Identität von Attestierern sicher zu bestätigen. Dadurch wird gewährleistet, dass nur verifizierte Parteien an der Autorisierung eines Container-Images beteiligt sind. Das Schlüsselpaar besteht aus einem privaten Schlüssel, mit dem der Attestierer Attestierungen digital signiert, und einem öffentlichen Schlüssel, den Sie dem Attestierer hinzufügen, wie er vom Binärautorisierungsdienst gespeichert wurde.

In dieser Anleitung verwenden Sie zum Erstellen des Schlüsselpaars den empfohlenen ECDSA (Elliptic Curve Digital Signing Algorithm). 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, asymmetrischen Schlüssel sind PKIX-konform. Weitere Informationen zur Verwendung von PKIX-Schlüsseln und Cloud KMS finden Sie unter Attestierer über die Befehlszeile erstellen.

Schlüsselpaar generieren

Ein PKIX-Schlüsselpaar besteht aus einem privaten Schlüssel, mit dem der Signer Attestierungen digital signiert, und einem öffentlichen Schlüssel, den Sie dem Attestierer hinzufügen. Beim Deployment verwendet die Binärautorisierung diesen öffentlichen Schlüssel, um die vom privaten Schlüssel signierte Attestierung zu prüfen.

1. Erstellen Sie den privaten Schlüssel:

   So erstellen Sie ein neues lokales asymmetrisches PKIX-Schlüsselpaar und speichern es in einer Datei:

   PKIX (Cloud KMS)

   In diesem Schritt wird gezeigt, wie Sie eine Attestierung mit Schlüsseln durchführen, die im Cloud Key Management Service erstellt und gespeichert wurden.

   1. Richten Sie Umgebungsvariablen ein, um Informationen über das von Cloud KMS verwaltete Schlüsselpaar zu speichern:

      Wenn Sie bereits ein Schlüsselpaar haben, können Sie diese Umgebungsvariablen festlegen und den nächsten Schritt überspringen.

      KMS_KEY_PROJECT_ID=KMS_KEY_PROJECT_ID
      KMS_KEY_LOCATION=KMS_KEY_LOCATION
      KMS_KEYRING_NAME=KMS_KEYRING_NAME
      KMS_KEY_NAME=KMS_KEY_NAME
      KMS_KEY_VERSION=KMS_KEY_VERSION
      

      Dabei gilt:

      • KMS_KEY_PROJECT_ID: die ID des Projekts, in dem die Schlüssel gespeichert sind.
      • KMS_KEY_LOCATION: der Speicherort des Schlüssels
      • KMS_KEYRING_NAME: der Name des Schlüsselbunds
      • KMS_KEY_NAME: der Name des Schlüssels
      • KMS_KEY_VERSION: die Schlüsselversion

   2. Optional: Richten Sie einen KMS-Schlüssel ein:

      Hinweis: Sie können diese Schritte überspringen, wenn Sie bereits einen KMS-Schlüssel haben.

      1. Erstellen Sie einen KMS-Schlüssel, dessen öffentlicher Schlüssel in einem Attestierer gespeichert werden kann. Mit diesem Schritt werden auch Umgebungsvariablen eingerichtet, die Sie weiter unten verwenden.

         So erstellen Sie einen Schlüssel und richten die Umgebungsvariablen ein:

         KMS_KEY_PROJECT_ID=${PROJECT_ID}
         KMS_KEYRING_NAME=my-binauthz-keyring
         KMS_KEY_NAME=my-binauthz-kms-key-name
         KMS_KEY_LOCATION=global
         KMS_KEY_PURPOSE=asymmetric-signing
         KMS_KEY_ALGORITHM=ec-sign-p256-sha256
         KMS_PROTECTION_LEVEL=software
         KMS_KEY_VERSION=1
         

      2. Erstellen Sie einen KMS-Schlüsselbund:

         gcloud kms keyrings create ${KMS_KEYRING_NAME} \
           --location ${KMS_KEY_LOCATION} \
           --project ${KMS_KEY_PROJECT_ID}
         

      3. Erstellen Sie den Schlüssel:

         gcloud kms keys create ${KMS_KEY_NAME} \
           --location ${KMS_KEY_LOCATION} \
           --keyring ${KMS_KEYRING_NAME}  \
           --purpose ${KMS_KEY_PURPOSE} \
           --default-algorithm ${KMS_KEY_ALGORITHM} \
           --protection-level ${KMS_PROTECTION_LEVEL} \
           --project ${KMS_KEY_PROJECT_ID}
         

         Weitere Informationen zum Erstellen von KMS-Schlüsseln finden Sie unter Asymmetrischen Schlüssel erstellen.

   3. Fügen Sie dem Attestierer den öffentlichen Schlüssel hinzu:

      gcloud --project="${ATTESTOR_PROJECT_ID}" \
          container binauthz attestors public-keys add \
          --attestor="${ATTESTOR_NAME}" \
          --keyversion-project="${KMS_KEY_PROJECT_ID}" \
          --keyversion-location="${KMS_KEY_LOCATION}" \
          --keyversion-keyring="${KMS_KEYRING_NAME}" \
          --keyversion-key="${KMS_KEY_NAME}" \
          --keyversion="${KMS_KEY_VERSION}"
      

   PKIX (lokaler Schlüssel)

   Warnung: Wir raten dringend davon ab, lokal generierte Schlüsselpaare in Produktionsumgebungen zu verwenden, da sie ein Sicherheitsrisiko darstellen. Wir empfehlen stattdessen die Verwendung des Cloud Key Management Service. Dieses Beispiel dient nur zur Veranschaulichung.

   1. Führen Sie die folgenden Befehle aus, um den privaten Schlüssel zu generieren:

      PRIVATE_KEY_FILE="/tmp/ec_private.pem"
      openssl ecparam -genkey -name prime256v1 -noout -out ${PRIVATE_KEY_FILE}
      

      PRIVATE_KEY_FILE ist der Name der Datei, die den privaten Schlüssel enthält, der im Attestierer gespeichert ist.

   2. Extrahieren Sie den öffentlichen Schlüssel aus dem privaten Schlüssel und speichern Sie ihn in einer Datei:

      PUBLIC_KEY_FILE="/tmp/ec_public.pem"
      openssl ec -in ${PRIVATE_KEY_FILE} -pubout -out ${PUBLIC_KEY_FILE}
      

      PUBLIC_KEY_FILE ist der Name der Datei, die den öffentlichen Schlüssel enthält, der im Attestierer gespeichert ist.

   3. Führen Sie den folgenden Code aus, um den öffentlichen Schlüssel hinzuzufügen, den Sie in den Attestierer exportiert haben.

      gcloud --project="${ATTESTOR_PROJECT_ID}" \
        container binauthz attestors public-keys add \
        --attestor="${ATTESTOR_NAME}" \
        --pkix-public-key-file=${PUBLIC_KEY_FILE} \
        --pkix-public-key-algorithm=ecdsa-p256-sha256
      

      Die Binärautorisierung verwendet den öffentlichen Schlüssel im Attestierer, um die Attestierung zu prüfen.

Richtlinie konfigurieren

Jetzt können Sie im Deployer-Projekt die 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 System-Images 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/${ATTESTOR_PROJECT_ID}/attestors/${ATTESTOR_NAME}
       name: projects/${DEPLOYER_PROJECT_ID}/policy
   EOM
   

2. Importieren Sie die YAML-Richtliniendatei in die Binärautorisierung:

   gcloud --project=${DEPLOYER_PROJECT_ID} \
       container binauthz policy import /tmp/policy.yaml
   

Weitere Informationen zum Konfigurieren einer Richtlinie finden Sie unter Richtlinie über die Befehlszeile konfigurieren.

Richtlinie testen

In dieser Anleitung erstellen Sie eine Attestierung, z. B. öffentliche "Hello World!"-Images aus Container Registry und Artifact Registry. Anfangs blockiert der Erzwingungsblock, dass die Images bereitgestellt werden, da die erforderliche Attestierung nicht vorhanden ist.

So stellen Sie das Image bereit:

Container Registry

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

Artifact Registry

kubectl run hello-server --image us-docker.pkg.dev/google-samples/containers/gke/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 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 die Erklärung eines Attestierers, dass ein erforderlicher Prozess in Ihrer Pipeline abgeschlossen wurde und das betreffende Container-Image für das Deployment freigegeben ist. Die Attestierung selbst ist ein digital signierter Datensatz. Dieser enthält den vollständigen Pfad zu einer Version des Images, die in Ihrer Container-Image-Registry gespeichert ist, sowie die Identität des Attestierers.

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

So erstellen Sie eine Attestierung:

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

   Container Registry

   IMAGE_PATH="gcr.io/google-samples/hello-app"
   IMAGE_DIGEST="sha256:c62ead5b8c15c231f9e786250b07909daf6c266d0fcddd93fea882eb722c3be4"
   

   Artifact Registry

   IMAGE_PATH="us-docker.pkg.dev/google-samples/containers/gke/hello-app"
   IMAGE_DIGEST="sha256:37e5287945774f27b418ce567cd77f4bbc9ef44a1bcd1a2312369f31f9cce567"
   IMAGE_TO_ATTEST=${IMAGE_PATH}@${IMAGE_DIGEST}
   

2. Attestierung erstellen

   PKIX Cloud KMS

   Führen Sie folgenden Befehl aus, um die Attestierung mit dem Cloud KMS-Schlüssel zu erstellen:

   gcloud beta container binauthz attestations sign-and-create \
       --project="${PROJECT_ID}" \
       --artifact-url="${IMAGE_TO_ATTEST}" \
       --attestor="${ATTESTOR_NAME}" \
       --attestor-project="${PROJECT_ID}" \
       --keyversion-project="${KMS_KEY_PROJECT_ID}" \
       --keyversion-location="${KMS_KEY_LOCATION}" \
       --keyversion-keyring="${KMS_KEYRING_NAME}" \
       --keyversion-key="${KMS_KEY_NAME}" \
       --keyversion="${KMS_KEY_VERSION}"
   

   PKIX (lokaler Schlüssel)

   So erstellen Sie die Attestierung mit einem lokalen Schlüssel:

   1. Erstellen Sie die Attestierungsnutzlast:

      Hinweis: Im folgenden Befehl ist zwar ein ${IMAGE_PATH} erforderlich, um die Signaturnutzlast für die Attestierung zu erstellen, aber zum Zeitpunkt des Deployments wird nur der ${IMAGE_DIGEST} verwendet. Dies bedeutet, dass Sie mit derselben Attestierung ein identisches Container-Image von mehreren Standorten aus bereitstellen können.

      gcloud --project=${ATTESTATION_PROJECT_ID} \
        container binauthz create-signature-payload \
        --artifact-url=${IMAGE_TO_ATTEST} > /tmp/generated_payload.json
      

      Die JSON-Nutzlastdatei hat folgenden Inhalt:

      Container Registry

      {
      "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

      {
      "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"
      }
      }
      

   2. Signieren Sie die Nutzlast.

      Wenn Sie lokale PKIX-Dateien verwenden, signieren Sie die Nutzlast mit dem lokalen 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 Ausgabedatei ist eine signierte Version der JSON-Nutzlastdatei, die Sie oben erstellt haben.

   3. Rufen Sie die ID des öffentlichen Schlüssels vom Attestierer ab.

      Sie können die ID Ihres öffentlichen Schlüssels jederzeit mit dem folgenden Befehl abrufen: gcloud container binauthz attestors describe ATTESTOR_NAME.

      Um die ID des öffentlichen Schlüssels in einer Umgebungsvariablen zu speichern, geben Sie den folgenden Befehl ein:

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

   4. Erstellen und validieren Sie die Attestierung:

      gcloud container binauthz attestations create \
        --project="${ATTESTATION_PROJECT_ID}" \
        --artifact-url="${IMAGE_TO_ATTEST}" \
        --attestor="projects/${ATTESTOR_PROJECT_ID}/attestors/${ATTESTOR_NAME}" \
        --signature-file=/tmp/ec_signature \
        --public-key-id="${PUBLIC_KEY_ID}" \
        --validate
      

      Das Flag validate prüft, ob die Attestierung von dem Attestierer geprüft werden kann, den Sie in Ihrer Richtlinie konfiguriert haben.

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

   gcloud --project=${ATTESTATION_PROJECT_ID} \
       container binauthz attestations list \
       --attestor=$ATTESTOR_NAME --attestor-project=$ATTESTOR_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 dem Image eine Attestierung zugeordnet ist.

So stellen Sie das Image bereit:

kubectl run hello-server --image ${IMAGE_TO_ATTEST} --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

Nachdem Sie nun das Container-Image erfolgreich bereitgestellt und gesehen haben, dass die Einrichtung funktioniert, können Sie den in GKE erstellten Cluster löschen:

gcloud --project=${DEPLOYER_PROJECT_ID} \
    container clusters delete \
    --zone=us-central1-a \
    test-cluster

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.

1. Löschen Sie den Cluster, den Sie in GKE erstellt haben:

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

2. Sie können auch Google Cloud-Projekte löschen, die Sie für diese Anleitung erstellt haben.

Nächste Schritte

• Weitere Informationen zur Binärautorisierung
• Schlüsselkonzepte der Binärautorisierung kennenlernen
• Probelaufmodus aktivieren, um die Erzwingung zu deaktivieren
• Break-Glass verwenden, um die Erzwingung zu umgehen