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:

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.

Hinweise

  1. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

  2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  3. Make sure that billing is enabled for your Google Cloud project.

  4. Install the Google Cloud CLI.

  5. To initialize the gcloud CLI, run the following command: 

    gcloud init

  6. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  7. Make sure that billing is enabled for your Google Cloud project.

  8. Install the Google Cloud CLI.

  9. To initialize the gcloud CLI, run the following command: 

    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.

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:

      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)

    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:

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