Mehrere Projekte einrichten

Sie können die Binärautorisierung in Ihrer Umgebung in einer Konfiguration mit einem Projekt oder einer Konfiguration mit mehreren Projekten einrichten. Eine Konfiguration mit mehreren Projekten eignet sich für die meisten Praxisanwendungen mit Binärautorisierung, bei denen mehrere Personen mit verschiedenen Rollen für verschiedene Phasen des Workflows der Softwarelieferkette verantwortlich sind. Dies ist unter dem Begriff Aufgabentrennung bekannt. Beispielsweise kann es folgende Rollen geben:

  • Deployer: Eine Person oder ein automatischer Prozess die oder der eine Anwendung gemäß der Unternehmensrichtlinie in GKE bereitstellt. Hier liegt der Schwerpunkt auf dem Deployment der Software. Die Aufgabe wird normalerweise von einem Softwareentwickler oder DevOps-Entwickler erledigt.

  • Security Operations (SecOps) Manager: Person, die die autorisierten, von der Binärautorisierung verwendeten Schlüssel verwaltet, um Richtlinien zu erzwingen, die eine Attestierung gemäß der Unternehmensrichtlinie erfordern. Diese Person kann auch die Richtlinien, Regeln und Attestierer erstellen. Mit diesen Attestierern wird letztendlich eine Attestierung geprüft und genehmigt, dass ein Container in GKE bereitgestellt werden kann. Daher hat nur diese Rolle Schreibzugriff auf den Attestierer.

  • Attestierungsmanager: Person, die die von den Attestierern benötigten Attestierungen erstellt und verwaltet. Diese Person erzeugt und verwaltet die kryptografischen Schlüssel. Anschließend signiert sie einen Container-Image-Deskriptor, um Attestierungen zu erstellen. Anschließend verwaltet sie die Attestierungen.

In dieser Anleitung wird beschrieben, wie Sie für jede der oben genannten Rollen ein separates Projekt einrichten können. Das heißt, Sie richten für den Deployer ein Deployer-Projekt, für den Sicherheitsmanager ein Attestiererprojekt und für den Attestierungsmanager ein Attestierungsprojekt ein.

Anschließend konfigurieren Sie Ihre Richtlinie für die Binärautorisierung mit Regeln, die Attestierungen erfordern. Abschließend testen Sie ein Deployment.

Jedes Projekt wird über die Identitäts- und Zugriffsverwaltung mit einer entsprechenden Zugriffssteuerung konfiguriert.

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.

Deployer-Projekt einrichten

Die Einrichtung des Deployer-Projekts ist der erste Schritt.

Ein Deployer-Projekt verwaltet die Google Kubernetes Engine-Cluster (GKE), in denen Ihre Images bereitgestellt werden, sowie die Richtlinie für Binärautorisierung, die das Deployment steuert. 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 Projektnamens und der Projektnummer fest:

    DEPLOYER_PROJECT_ID=PROJECT_ID
    

    Dabei ist PROJECT_ID der Name des Projekts in Google Cloud.

    DEPLOYER_PROJECT_NUMBER=$(gcloud projects describe "${DEPLOYER_PROJECT_ID}" \
        --format="value(projectNumber)")
    
  4. Aktivieren Sie die Binärautorisierung und die GKE APIs:

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

    Dabei ist PROJECT_ID der Name des Projekts in Google Cloud.

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

    Dabei ist PROJECT_ID der Name des Projekts in Google Cloud.

  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 beta container clusters create.

So erstellen Sie den Cluster:

gcloud --project=${DEPLOYER_PROJECT_ID} \
    beta 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
    
  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} \
        beta 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} \
        beta 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} \
    beta 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 Signaturalgorithmen 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}" \
      beta 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 ist die ID des Projekts, in dem die Schlüssel gespeichert sind
      • KMS_KEY_LOCATION ist der Speicherort des Schlüssels
      • KMS_KEYRING_NAME ist der Name des Schlüsselbunds
      • KMS_KEY_NAME ist der Name des Schlüssels
      • KMS_KEY_VERSION ist 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}" \
          alpha 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} \
        beta 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.

So stellen Sie das Image bereit:

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

Prüfen Sie, ob das Deployment durch die Binärautorisierung blockiert wurde:

kubectl get pods

Der Befehl gibt die folgende Meldung aus, dass das Image nicht bereitgestellt wurde:

No resources found.

Sie können weitere Details zum Deployment abrufen:

kubectl get event --template \
'{{range.items}}{{"\033[0;36m"}}{{.reason}}:{{"\033[0m"}}\{{.message}}{{"\n"}}{{end}}'

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

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

    gcloud --project=${ATTESTATION_PROJECT_ID} \
        beta 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. 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 Signaturdatei ist eine digital signierte Version der JSON-Nutzlastdatei, die Sie oben erstellt haben.

  4. Wenn Sie Cloud KMS verwenden, signieren Sie die Nutzlast mit dem Cloud KMS-Dienst:

      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}
    
  5. 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})
    
  6. Erstellen Sie eine URL für das zu attestierende Image:

    IMAGE_TO_ATTEST=${IMAGE_PATH}@${IMAGE_DIGEST}
    
  7. Attestierung erstellen:

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

    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 \
        --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
    
  8. Prüfen Sie, ob die Attestierung erstellt wurde:

    gcloud --project=${ATTESTATION_PROJECT_ID} \
        beta 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 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

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