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 dem gcloud-Befehlszeilentool (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 dieser Anleitung werden die folgenden kostenpflichtigen Komponenten von Google Cloud verwendet:

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 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. Wählen Sie in der Google Cloud Console auf der Seite der Projektauswahl ein Google Cloud-Projekt aus oder erstellen Sie eines.

    Zur Projektauswahl

  6. Die Abrechnung für das Cloud-Projekt muss aktiviert sein. So prüfen Sie, ob die Abrechnung für Ihr Projekt aktiviert ist.

  7. Installieren und initialisieren Sie das Cloud SDK.
  8. 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 Container Analysis-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 Container 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 Container Analysis-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 Container Analysis-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 Container 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 --enable-binauthz an den Befehl gcloud container clusters create.

So erstellen Sie den Cluster:

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

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 Container Analysis 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.
  • Legen Sie die Berechtigungen für den Container Analysis-Hinweis fest.

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.

Container Analysis-Hinweis erstellen

  1. Legen Sie Variablen fest, in denen der Name des Attestierers und der Container Analysis-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 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/${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

Legen Sie die Berechtigungen für den Container Analysis-Hinweis fest.

Sie müssen auch Berechtigungen für den von Ihnen erstellten Container Analysis-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}'
            ]
          }
        ]
      }
    }
    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 (lokaler Schlüssel)

    1. Erstellen Sie den privaten Schlüssel:

      PRIVATE_KEY_FILE ist der Name der Datei, die den privaten Schlüssel zum Signieren der Attestierungsnutzlast enthält.

      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 und speichern Sie ihn in einer Datei:

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

      PUBLIC_KEY_FILE="/tmp/ec_public.pem"
      openssl ec -in ${PRIVATE_KEY_FILE} -pubout -out ${PUBLIC_KEY_FILE}
      
      1. Fügen Sie den lokalen öffentlichen 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="${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
      

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

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"
    
  2. Erstellen Sie die Attestierungsnutzlast:

    gcloud --project=${ATTESTATION_PROJECT_ID} \
        container binauthz create-signature-payload \
        --artifact-url=${IMAGE_PATH}@${IMAGE_DIGEST} > /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"
      }
    }
    
  3. Signieren Sie die Nutzlast.

    PKIX (lokaler Schlüssel)

    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.

    PKIX (Cloud Key Management Service)

    Signieren Sie die Nutzlast mit dem Cloud Key Management Service:

      gcloud kms asymmetric-sign \
            --location=${KMS_KEY_LOCATION} \
            --keyring=${KMS_KEYRING_NAME} \
            --key=${KMS_KEY_NAME} \
            --version=${KMS_KEY_VERSION} \
            --digest-algorithm=sha256 \
            --input-file=/tmp/generated_payload.json \
            --signature-file=/tmp/ec_signature \
            --project ${KMS_KEY_PROJECT_ID}
    
  4. 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 <var>ATTESTOR_NAME</var>.

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

    PUBLIC_KEY_ID=$(gcloud container binauthz attestors describe ${ATTESTOR_NAME} \
    --format='value(userOwnedGrafeasNote.publicKeys[0].id)' --project ${ATTESTOR_PROJECT_ID})
    
  5. Erstellen Sie eine URL für das zu attestierende Image:

    IMAGE_TO_ATTEST=${IMAGE_PATH}@${IMAGE_DIGEST}
    
  6. 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.

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