Einfache Prüfung auf Attestierungsignatur

Auf dieser Seite erfahren Sie, wie Sie die einfache CV-Prüfung auf Attestierungsignatur (Continuous Validation) für die Binärautorisierung verwenden. Die Prüfung verifiziert die Attestierungen von Container-Images, die mit Pods verknüpft sind, die in einem GKE-Cluster (Google Kubernetes Engine) ausgeführt werden, in dem CV aktiviert ist.

Kosten

In diesem Leitfaden werden folgende Google Cloud-Dienste verwendet.

  • Binärautorisierung, aber CV ist in der Vorschauphase kostenlos.
  • GKE
  • Cloud Key Management Service

Mit dem Preisrechner können Sie eine Kostenschätzung für Ihre voraussichtliche Nutzung vornehmen.

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. Install the Google Cloud CLI.
  3. To initialize the gcloud CLI, run the following command:

    gcloud init
  4. Create or select a Google Cloud project.

    • Create a Google Cloud project:

      gcloud projects create PROJECT_ID

      Replace PROJECT_ID with a name for the Google Cloud project you are creating.

    • Select the Google Cloud project that you created:

      gcloud config set project PROJECT_ID

      Replace PROJECT_ID with your Google Cloud project name.

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

  6. Enable the Binary Authorization, Cloud Key Management Service, Google Kubernetes Engine APIs:

    gcloud services enable binaryauthorization.googleapis.com cloudkms.googleapis.com container.googleapis.com
  7. Install the Google Cloud CLI.
  8. To initialize the gcloud CLI, run the following command:

    gcloud init
  9. Create or select a Google Cloud project.

    • Create a Google Cloud project:

      gcloud projects create PROJECT_ID

      Replace PROJECT_ID with a name for the Google Cloud project you are creating.

    • Select the Google Cloud project that you created:

      gcloud config set project PROJECT_ID

      Replace PROJECT_ID with your Google Cloud project name.

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

  11. Enable the Binary Authorization, Cloud Key Management Service, Google Kubernetes Engine APIs:

    gcloud services enable binaryauthorization.googleapis.com cloudkms.googleapis.com container.googleapis.com
  12. Prüfen Sie, ob die gcloud CLI auf die neueste Version aktualisiert ist.
  13. Installieren Sie das kubectl-Befehlszeilentool
  14. Wenn sich Ihre Richtlinien für die Binärautorisierung und GKE-Cluster in verschiedenen Projekten befinden, muss die Binärautorisierung in beiden Projekten aktiviert sein.

Erforderliche Rollen

In diesem Abschnitt erfahren Sie, wie Sie Rollen für diese Prüfung festlegen.

Überblick

Wenn Sie alle in dieser Anleitung erwähnten Produkte im selben Projekt ausführen, müssen Sie keine Berechtigungen festlegen. Die Binärautorisierung konfiguriert die Rollen korrekt, wenn Sie sie aktivieren. Wenn Sie die Produkte in verschiedenen Projekten ausführen, müssen Sie Rollen festlegen, wie in diesem Abschnitt beschrieben.

Um sicherzustellen, dass der Dienst-Agent für die Binärautorisierung in jedem Projekt die erforderlichen Berechtigungen zur Auswertung der einfachen CV-Prüfung auf Attestierungsignatur hat, bitten Sie Ihren Administrator, dem Dienst-Agent für die Binärautorisierung in jedem Projekt die folgenden IAM-Rollen zu gewähren:

  • Wenn sich Ihr Clusterprojekt vom Richtlinienprojekt unterscheidet: Bewerter für Richtlinien für Binärautorisierungen (roles/binaryauthorization.policyEvaluator) im Dienst-Agent für die Binärautorisierung für das Clusterprojekt, um auf das Richtlinienprojekt zuzugreifen
  • Wenn sich Ihr Attestierungsprojekt von Ihrem Richtlinienprojekt unterscheidet: Betrachter von Container Analysis-Vorkommen (roles/containeranalysis.occurrences.viewer) für den Dienst-Agent für Binärautorisierungen des Richtlinienprojekts, damit er auf das Attestierungsprojekt zugreifen kann

Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff verwalten.

Ihr Administrator kann möglicherweise auch dem Dienst-Agent für die Binärautorisierung in jedem Projekt die erforderlichen Berechtigungen über benutzerdefinierte Rollen oder andere vordefinierte Rollen erteilen.

Rollen mit der gcloud CLI gewähren

Damit der Dienst-Agent für die Binärautorisierung in jedem Projekt die erforderlichen Berechtigungen zur Auswertung der CV-Prüfung auf Attestierungsignatur hat, müssen Sie ihm in jedem Projekt die folgenden IAM-Rollen zuweisen:

  1. Gewähren Sie dem Dienst-Agent für Binärautorisierung des Clusterprojekts die Berechtigung, auf die Richtlinie im Richtlinienprojekt zuzugreifen.

    1. Rufen Sie den Dienst-Agent für die Binärautorisierung des Clusterprojekts ab:

      PROJECT_NUMBER=$(gcloud projects list --filter="projectId:CLUSTER_PROJECT_ID" \
        --format="value(PROJECT_NUMBER)")
      CLUSTER_SERVICE_ACCOUNT="service-$PROJECT_NUMBER@gcp-sa-binaryauthorization.iam.gserviceaccount.com"
      

      Ersetzen Sie CLUSTER_PROJECT_ID durch die Projekt-ID des Clusters.

    2. CV die Bewertung der Richtlinie im Cluster erlauben:

      gcloud projects add-iam-policy-binding POLICY_PROJECT_ID \
          --member="serviceAccount:$CLUSTER_SERVICE_ACCOUNT" \
          --role='roles/binaryauthorization.policyEvaluator'
      

      Ersetzen Sie POLICY_PROJECT_ID durch die ID des Projekts, das Ihre Richtlinie enthält.

  2. Gewähren Sie dem Dienst-Agent für die Binärautorisierung des Richtlinienprojekts Zugriff auf die Attestierungen in Ihrem Attestierungsprojekt:

    1. Rufen Sie den Dienst-Agent für die Binärautorisierung des Richtlinienprojekts ab:

      PROJECT_NUMBER=$(gcloud projects list \
        --filter="projectId:POLICY_PROJECT_ID" \
        --format="value(PROJECT_NUMBER)")
      SERVICE_ACCOUNT="service-$PROJECT_NUMBER@gcp-sa-binaryauthorization.iam.gserviceaccount.com"
      

      Ersetzen Sie POLICY_PROJECT_ID durch die ID des Projekts, das Ihre Richtlinie enthält.

    2. Weisen Sie die Rolle zu:

      gcloud projects add-iam-policy-binding ATTESTATION_PROJECT_ID \
          --member="serviceAccount:$SERVICE_ACCOUNT" \
          --role='roles/containeranalysis.occurrences.viewer'
      

      Ersetzen Sie ATTESTATION_PROJECT_ID durch die ID des Projekts, das Ihre Attestierungen enthält.

Ein Schlüsselpaar erstellen

In diesem Abschnitt erstellen Sie ein asymmetrisches ECDSA-Schlüsselpaar (Elliptic Curve Digital Signature Algorithm).

Signieren Sie das Image mit dem privaten Schlüssel, um die Attestierung zu erstellen. Sie fügen den öffentlichen Schlüssel in eine Plattformrichtlinie ein. Wenn CV die Attestierung prüft, verwendet er den öffentlichen Schlüssel, um die Attestierung zu verifizieren.

Sie können entweder den Cloud Key Management Service oder lokale Schlüssel verwenden. Wir empfehlen jedoch, für die Produktion Cloud KMS-Schlüssel zu verwenden.

PKIX Cloud KMS

So erstellen Sie das Schlüsselpaar in Cloud KMS:

  1. Richten Sie Umgebungsvariablen ein, die zum Erstellen des Schlüsselpaars erforderlich sind. Dazu empfehlen wir, die Platzhalter im folgenden Befehl auszufüllen und dann den Befehl auszuführen.

    KMS_KEY_PROJECT_ID=KMS_KEY_PROJECT_ID
    KMS_KEYRING_NAME=KMS_KEYRING_NAME
    KMS_KEY_NAME=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
    

    Ersetzen Sie Folgendes:

    • KMS_KEY_PROJECT_ID: Ihre Projekt-ID.
    • KMS_KEYRING_NAME: ein Name für Ihren Cloud KMS-Schlüsselbund
    • KMS_KEY_NAME: ein Name für Ihren Cloud KMS-Schlüssel
  2. Erstellen Sie den 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}
    
  4. Exportieren Sie das Material des öffentlichen Schlüssels in eine Datei:

    gcloud kms keys versions get-public-key 1 \
        --key=${KMS_KEY_NAME} \
        --keyring=${KMS_KEYRING_NAME} \
        --location=${KMS_KEY_LOCATION} \
        --output-file=/tmp/ec_public.pem \
        --project=${KMS_KEY_PROJECT_ID}
    

Lokaler Schlüssel

So erstellen Sie das Schlüsselpaar lokal:

  1. Erstellen Sie den privaten Schlüssel:

    PRIVATE_KEY_FILE="/tmp/ec_private.pem"
    openssl ecparam -genkey -name prime256v1 -noout -out ${PRIVATE_KEY_FILE}
    
  2. Rufen Sie den öffentlichen Schlüssel aus dem privaten Schlüssel ab:

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

Eine Plattformrichtlinie erstellen

So erstellen Sie eine CV-Plattformrichtlinie mit einer einfachen Prüfung auf Attestierungsignatur:

  1. Erstellen Sie die YAML-Datei der Plattformrichtlinie für die einfache Prüfung auf Attestierungsignatur:

    PKIX Cloud KMS

    cat > /tmp/my-policy.yaml <<EOF
    gkePolicy:
      checkSets:
        checks:
          simpleSigningAttestationCheck:
            containerAnalysisAttestationProjects:
            - projects/ATTESTATION_PROJECT_ID
            attestationAuthenticators:
              pkixPublicKeySet:
                pkixPublicKeys:
                  publicKeyPem: |
    $(awk '{printf "                %s\n", $0}' /tmp/ec_public.pem)
                  signatureAlgorithm: ECDSA_P256_SHA256
                  keyId: |
                    projects/KMS_KEY_PROJECT_ID/locations/${KMS_KEY_LOCATION}/keyRings/${KMS_KEYRING_NAME}/cryptoKeys/${KMS_KEY_NAME}/cryptoKeyVersions/${KMS_KEY_VERSION}
    EOF
    

    Ersetzen Sie Folgendes:

    • ATTESTATION_PROJECT_ID: Die ID des Projekts, in dem die Attestierungen gespeichert sind
    • KMS_KEY_PROJECT_ID: die ID Ihres KMS-Schlüsselprojekts

    Lokaler Schlüssel

    cat > /tmp/my-policy.yaml <<EOF
    gkePolicy:
      checkSets:
        checks:
          simpleSigningAttestationCheck:
            containerAnalysisAttestationProjects:
            - "projects/ATTESTATION_PROJECT_ID"
            attestationAuthenticators:
              pkixPublicKeySet:
                pkixPublicKeys:
                  publicKeyPem: |
    $(awk '{printf "                %s\n", $0}' /tmp/ec_public.pem)
                  signatureAlgorithm: ECDSA_P256_SHA256
                  keyId: |
                    PUBLIC_KEY_ID
    EOF
    

    Ersetzen Sie Folgendes:

    • ATTESTATION_PROJECT_ID: Die ID des Projekts, in dem die Attestierungen gespeichert sind
    • PUBLIC_KEY_ID: eine ID, die Ihren lokalen Schlüssel eindeutig identifiziert
  2. Erstellen Sie die Plattformrichtlinie:

    Ersetzen Sie folgende Werte, bevor sie einen der Befehlsdaten verwenden:

    • POLICY_ID: Eine Plattformrichtlinien-ID Ihrer Wahl. Wenn sich die Richtlinie in einem anderen Projekt befindet, können Sie den vollständigen Ressourcennamen verwenden: projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID.
    • POLICY_PATH: Ein Pfad zur Richtliniendatei.
    • POLICY_PROJECT_ID: Die ID des Richtlinienprojekts.

    Führen Sie folgenden Befehl aus:

    Linux, macOS oder Cloud Shell

    gcloud beta container binauthz policy create POLICY_ID \
        --platform=gke \
        --policy-file=POLICY_PATH \
        --project=POLICY_PROJECT_ID

    Windows (PowerShell)

    gcloud beta container binauthz policy create POLICY_ID `
        --platform=gke `
        --policy-file=POLICY_PATH `
        --project=POLICY_PROJECT_ID

    Windows (cmd.exe)

    gcloud beta container binauthz policy create POLICY_ID ^
        --platform=gke ^
        --policy-file=POLICY_PATH ^
        --project=POLICY_PROJECT_ID

  3. Speichern Sie den ID-Wert für die spätere Verwendung:

    PUBLIC_KEY_ID="PUBLIC_KEY_ID"
    

    Ersetzen Sie PUBLIC_KEY_ID durch die ID, die Sie zuvor im Feld keyId in der Plattformrichtliniendatei in dieser Anleitung angegeben haben.

    Der private Schlüssel wird beim Erstellen von Attestierungen verwendet, wie weiter unten in dieser Anleitung beschrieben.

CV aktivieren

Sie können einen neuen Cluster erstellen oder einen vorhandenen Cluster aktualisieren, um das CV-Monitoring mit prüfbasierten Plattformrichtlinien zu verwenden.

Cluster erstellen, der das CV-Monitoring verwendet

In diesem Abschnitt erstellen Sie einen Cluster, der nur das CV-Monitoring mit prüfbasierten Plattformrichtlinien verwendet.

Ersetzen Sie folgende Werte, bevor sie einen der Befehlsdaten verwenden:

  • CLUSTER_NAME: ein Clustername
  • LOCATION: Der Standort, z. B. us-central1 oder asia-south1
  • POLICY_PROJECT_ID: Die ID des Projekts, in dem die Richtlinie gespeichert ist.
  • POLICY_ID: Die Richtlinien-ID.
  • CLUSTER_PROJECT_ID: Die Cluster-Projekt-ID

Führen Sie folgenden Befehl aus:

Linux, macOS oder Cloud Shell

gcloud beta container clusters create CLUSTER_NAME \
    --location=LOCATION \
    --binauthz-evaluation-mode=POLICY_BINDINGS \
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID \
    --project=CLUSTER_PROJECT_ID

Windows (PowerShell)

gcloud beta container clusters create CLUSTER_NAME `
    --location=LOCATION `
    --binauthz-evaluation-mode=POLICY_BINDINGS `
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID `
    --project=CLUSTER_PROJECT_ID

Windows (cmd.exe)

gcloud beta container clusters create CLUSTER_NAME ^
    --location=LOCATION ^
    --binauthz-evaluation-mode=POLICY_BINDINGS ^
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID ^
    --project=CLUSTER_PROJECT_ID

Cluster mit Erzwingung und CV-Monitoring erstellen

In diesem Abschnitt erstellen Sie einen Cluster, der sowohl die Erzwingung der Projekt-Singleton-Richtlinie als auch das CV-Monitoring mit prüfbasierten Plattformrichtlinien verwendet:

Ersetzen Sie folgende Werte, bevor sie einen der Befehlsdaten verwenden:

  • CLUSTER_NAME: ein Clustername
  • LOCATION: Der Standort, z. B. us-central1 oder asia-south1
  • POLICY_PROJECT_ID: Die ID des Projekts, in dem die Richtlinie gespeichert ist.
  • POLICY_ID: Die Richtlinien-ID.
  • CLUSTER_PROJECT_ID: Die Cluster-Projekt-ID

Führen Sie folgenden Befehl aus:

Linux, macOS oder Cloud Shell

gcloud beta container clusters create CLUSTER_NAME \
    --location=LOCATION \
    --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE \
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID \
    --project=CLUSTER_PROJECT_ID

Windows (PowerShell)

gcloud beta container clusters create CLUSTER_NAME `
    --location=LOCATION `
    --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE `
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID `
    --project=CLUSTER_PROJECT_ID

Windows (cmd.exe)

gcloud beta container clusters create CLUSTER_NAME ^
    --location=LOCATION ^
    --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE ^
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID ^
    --project=CLUSTER_PROJECT_ID

Cluster zur Verwendung des CV-Monitoring aktualisieren

In diesem Abschnitt aktualisieren Sie einen Cluster, um das CV-Monitoring nur mit prüfbasierten Plattformrichtlinien zu verwenden. Wenn für den Cluster bereits die Erzwingung der Projekt-Singleton-Richtlinie aktiviert ist, wird sie durch Ausführen dieses Befehls deaktiviert. Stattdessen sollten Sie den Cluster mit aktivierter Erzwingung und aktiviertem CV-Monitoring aktualisieren.

Ersetzen Sie folgende Werte, bevor sie einen der Befehlsdaten verwenden:

  • CLUSTER_NAME: Der Clustername
  • LOCATION: Der Standort, z. B. us-central1 oder asia-south1
  • POLICY_PROJECT_ID: die ID des Projekts, in dem die Richtlinie gespeichert ist
  • POLICY_ID: die Richtlinien-ID
  • CLUSTER_PROJECT_ID: Die Cluster-Projekt-ID

Führen Sie folgenden Befehl aus:

Linux, macOS oder Cloud Shell

gcloud beta container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --binauthz-evaluation-mode=POLICY_BINDINGS \
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID \
    --project=CLUSTER_PROJECT_ID

Windows (PowerShell)

gcloud beta container clusters update CLUSTER_NAME `
    --location=LOCATION `
    --binauthz-evaluation-mode=POLICY_BINDINGS `
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID `
    --project=CLUSTER_PROJECT_ID

Windows (cmd.exe)

gcloud beta container clusters update CLUSTER_NAME ^
    --location=LOCATION ^
    --binauthz-evaluation-mode=POLICY_BINDINGS ^
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID ^
    --project=CLUSTER_PROJECT_ID

Cluster aktualisieren, um Erzwingung und CV-Monitoring zu verwenden

In diesem Abschnitt aktualisieren Sie einen Cluster, um sowohl die Erzwingung der Projekt-Singleton-Richtlinie als auch das CV-Monitoring mit prüfbasierten Plattformrichtlinien zu verwenden.

Ersetzen Sie folgende Werte, bevor sie einen der Befehlsdaten verwenden:

  • CLUSTER_NAME: ein Clustername
  • LOCATION: Der Standort, z. B. us-central1 oder asia-south1
  • POLICY_PROJECT_ID: die ID des Projekts, in dem die Richtlinie gespeichert ist
  • POLICY_ID: die Richtlinien-ID
  • CLUSTER_PROJECT_ID: Die Cluster-Projekt-ID

Führen Sie folgenden Befehl aus:

Linux, macOS oder Cloud Shell

gcloud beta container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE \
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID \
    --project=CLUSTER_PROJECT_ID

Windows (PowerShell)

gcloud beta container clusters update CLUSTER_NAME `
    --location=LOCATION `
    --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE `
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID `
    --project=CLUSTER_PROJECT_ID

Windows (cmd.exe)

gcloud beta container clusters update CLUSTER_NAME ^
    --location=LOCATION ^
    --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE ^
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID ^
    --project=CLUSTER_PROJECT_ID

Artefaktanalyse-Hinweis erstellen

In diesem Abschnitt erstellen Sie ein Beispiel für einen Artefaktanalyse-Hinweis, um Attestierungen zu verknüpfen. So erstellen Sie den Hinweis:

  1. Erstellen Sie die Hinweisvariablen:

    NOTE_PROJECT_ID=NOTE_PROJECT_ID
    NOTE_ID="test-note"
    NOTE_URI="projects/${NOTE_PROJECT_ID}/notes/${NOTE_ID}"
    DESCRIPTION="CV test note"
    

    Ersetzen Sie NOTE_PROJECT_ID: die ID des Projekts, das den Hinweis enthält.

  2. Erstellen Sie die Datei mit dem Hinweisinhalt:

    cat > /tmp/note_payload.json << EOM
    {
      "name": "${NOTE_URI}",
      "attestation": {
        "hint": {
          "human_readable_name": "${DESCRIPTION}"
        }
      }
    }
    EOM
    
  3. Erstellen Sie den Hinweis:

    curl -X POST \
        -H "Content-Type: application/json" \
        -H "Authorization: Bearer $(gcloud auth print-access-token)"  \
        -H "x-goog-user-project: ${NOTE_PROJECT_ID}" \
        --data-binary @/tmp/note_payload.json "https://containeranalysis.googleapis.com/v1/projects/${NOTE_PROJECT_ID}/notes/?noteId=${NOTE_ID}"
    

    Ersetzen Sie NOTE_PROJECT_ID: die ID des Projekts, das den Hinweis enthält

  4. Optional: So prüfen Sie, ob Sie den Hinweis erstellt haben:

    curl \
        -H "Authorization: Bearer $(gcloud auth print-access-token)"  \
        -H "x-goog-user-project: NOTE_PROJECT_ID" \
    "https://containeranalysis.googleapis.com/v1/projects/NOTE_PROJECT_ID/notes/"
    

    Ersetzen Sie NOTE_PROJECT_ID durch die ID des Projekts, das den Hinweis enthält.

CV testen

In diesem Abschnitt testen Sie CV, indem Sie das Image bereitstellen, für das Sie eine Attestierung erstellt haben. In diesem Fall verifiziert die einfache Prüfung auf Attestierungsignatur die Attestierung und erzeugt keinen Logeintrag.

Anschließend versuchen Sie, ein anderes Image ohne Attestierung bereitzustellen. In diesem Fall kann die CV-Prüfung die Attestierung nicht finden und erfasst den Verstoß in Cloud Logging.

Attestierung erstellen

Zur Prüfung muss das Image eine gültige Attestierung haben. So erstellen Sie die Attestierung:

  1. Erstellen Sie die Variablen, mit denen Sie die Attestierung erstellen:

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

    cat > /tmp/generated_payload.json << EOM
    {
      "critical": {
        "identity": {
          "docker-reference": "${IMAGE_PATH}"
        },
        "image": {
          "docker-manifest-digest": "${IMAGE_DIGEST}"
        },
        "type": "Google cloud binauthz container signature"
      }
    }
    EOM
    
  3. Erstellen Sie die Attestierung:

    1. Signieren Sie die Nutzlast.

      PKIX Cloud KMS

      gcloud kms asymmetric-sign \
          --version=${KMS_KEY_VERSION} \
          --key=${KMS_KEY_NAME} \
          --keyring=${KMS_KEYRING_NAME} \
          --location=${KMS_KEY_LOCATION} --digest-algorithm sha256 \
          --input-file=/tmp/generated_payload.json \
          --signature-file=/tmp/ec_signature \
          --project=${KMS_KEY_PROJECT_ID}
      

      Lokaler Schlüssel

      openssl dgst -sha256 -sign ${PRIVATE_KEY_FILE} /tmp/generated_payload.json > /tmp/ec_signature
      
    2. Erstellen Sie den Attestierungsinhalt:

      cat > /tmp/attestation.json << EOM
      {
        "resourceUri": "${IMAGE_TO_ATTEST}",
        "note_name": "${NOTE_URI}",
        "attestation": {
          "serialized_payload": "$(base64 --wrap=0 /tmp/generated_payload.json)",
          "signatures": [{
            "public_key_id": "${PUBLIC_KEY_ID}",
            "signature": "$(base64 --wrap=0 /tmp/ec_signature)"
          }]
        }
      }
      EOM
      
    3. Erstellen Sie die Attestierung:

      curl -X POST "https://containeranalysis.googleapis.com/v1/projects/${NOTE_PROJECT_ID}/occurrences/" \
          -H "Content-Type: application/json" \
          -H "X-Goog-User-Project: ${NOTE_PROJECT_ID}" \
          -H "Authorization: Bearer $(gcloud auth print-access-token)" \
          --data-binary @/tmp/attestation.json
      

      Ersetzen Sie NOTE_PROJECT_ID durch die ID des Projekts, das den Hinweis enthält.

Image mit Attestierung bereitstellen

So stellen Sie ein Image bereit, für das eine Attestierung erstellt wurde:

  1. Konfigurieren Sie kubectl:

    gcloud container clusters get-credentials CLUSTER_NAME \
        --location=LOCATION \
        --project=CLUSTER_PROJECT_ID
    

    Ersetzen Sie Folgendes:

    • CLUSTER_NAME: der Name Ihres Clusters
    • LOCATION: der Clusterstandort
    • CLUSTER_PROJECT_ID: die Cluster-Projekt-ID
  2. Stellen Sie einen Dienst bereit und prüfen Sie die Bereitstellung anhand der Richtlinie für die Binärautorisierung:

    kubectl run hello-app --image=$IMAGE_PATH@$IMAGE_DIGEST
    

    Der Pod wurde bereitgestellt. Da das Image eine Attestierung hat, erstellt CV keine Logeinträge für diesen Pod.

Image ohne Attestierung bereitstellen

In diesem Abschnitt stellen Sie ein Image bereit, dem keine Attestierung zugeordnet ist.

Da die Richtlinie Attestierungen erfordert und dieses Image keine hat, protokolliert CV regelmäßig den Verstoß, während der Container ausgeführt wird.

Führen Sie den folgenden -Befehl aus, um das Image bereitzustellen:

kubectl run hello-app-no-attestation \
    --image=gcr.io/google-samples/hello-app@sha256:845f77fab71033404f4cfceaa1ddb27b70c3551ceb22a5e7f4498cdda6c9daea

Der Pod wurde bereitgestellt. Da das Image keine Attestierung hat, erzeugt CV während der Ausführung des Pods Logeinträge.

Logs für CV-Einträge ansehen

CV protokolliert Plattformrichtlinienverstöße in Cloud Logging innerhalb von 24 Stunden. Die Einträge werden in der Regel innerhalb weniger Stunden angezeigt.

Wenn keine Images gegen die von Ihnen aktivierten Plattformrichtlinien verstoßen, werden keine Einträge in den Logs angezeigt.

Führen Sie den folgenden Befehl aus, um die CV-Logeinträge der letzten sieben Tage anzusehen:

gcloud logging read \
     --order="desc" \
     --freshness=7d \
     --project=CLUSTER_PROJECT_ID \
    'logName:"binaryauthorization.googleapis.com%2Fcontinuous_validation" "policyName"'

Ersetzen Sie CLUSTER_PROJECT_ID durch die Clusterprojekt-ID.

Prüftypen

CV-Logs prüfen Informationen zu Verstößen in checkResults. Im Eintrag gibt der Wert checkType die Prüfung an. Die Werte für die einzelnen Prüfungen lauten so:

  • ImageFreshnessCheck
  • SigstoreSignatureCheck
  • SimpleSigningAttestationCheck
  • SlsaCheck
  • TrustedDirectoryCheck
  • VulnerabilityCheck

Beispiellog

Der folgende Beispiel-CV-Logging-Eintrag beschreibt ein nicht konformes Image, das gegen eine Prüfung auf vertrauenswürdige Verzeichnisse verstößt:

{
  "insertId": "637c2de7-0000-2b64-b671-24058876bb74",
  "jsonPayload": {
    "podEvent": {
      "endTime": "2022-11-22T01:14:30.430151Z",
      "policyName": "projects/123456789/platforms/gke/policies/my-policy",
      "images": [
        {
          "result": "DENY",
          "checkResults": [
            {
              "explanation": "TrustedDirectoryCheck at index 0 with display name \"My trusted directory check\" has verdict NOT_CONFORMANT. Image is not in a trusted directory",
              "checkSetName": "My check set",
              "checkSetIndex": "0",
              "checkName": "My trusted directory check",
              "verdict": "NON_CONFORMANT",
              "checkType": "TrustedDirectoryCheck",
              "checkIndex": "0"
            }
          ],
          "image": "gcr.io/my-project/hello-app:latest"
        }
      ],
      "verdict": "VIOLATES_POLICY",
      "podNamespace": "default",
      "deployTime": "2022-11-22T01:06:53Z",
      "pod": "hello-app"
    },
    "@type": "type.googleapis.com/google.cloud.binaryauthorization.v1beta1.ContinuousValidationEvent"
  },
  "resource": {
    "type": "k8s_cluster",
    "labels": {
      "project_id": "my-project",
      "location": "us-central1-a",
      "cluster_name": "my-test-cluster"
    }
  },
  "timestamp": "2022-11-22T01:44:28.729881832Z",
  "severity": "WARNING",
  "logName": "projects/my-project/logs/binaryauthorization.googleapis.com%2Fcontinuous_validation",
  "receiveTimestamp": "2022-11-22T03:35:47.171905337Z"
}

Bereinigen

In diesem Abschnitt wird beschrieben, wie Sie das zuvor in dieser Anleitung konfigurierte CV-Monitoring bereinigen.

Sie können das CV-Monitoring oder sowohl die Binärautorisierung als auch CV in Ihrem Cluster deaktivieren.

Binärautorisierung in einem Cluster deaktivieren

Führen Sie den folgenden Befehl aus, um die CV und Binärautorisierungserzwingung in Ihrem Cluster zu deaktivieren:

gcloud beta container clusters update CLUSTER_NAME \
    --binauthz-evaluation-mode=DISABLED \
    --location=LOCATION \
    --project=CLUSTER_PROJECT_ID

Ersetzen Sie Folgendes:

  • CLUSTER_NAME ist der Name des Clusters.
  • LOCATION: Der Clusterstandort
  • CLUSTER_PROJECT_ID: Die Cluster-Projekt-ID

Prüfbasiertes Richtlinien-Monitoring in einem Cluster deaktivieren

Führen Sie den folgenden Befehl aus, um CV mit prüfbasierten Richtlinien im Cluster zu deaktivieren und die Erzwingung mithilfe der Richtlinie für die Binärautorisierungserzwingung neu zu aktivieren:

gcloud beta container clusters update CLUSTER_NAME  \
    --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE \
    --location=LOCATION \
    --project="CLUSTER_PROJECT_ID"

Ersetzen Sie Folgendes:

  • CLUSTER_NAME ist der Name des Clusters.
  • LOCATION: Der Clusterstandort
  • CLUSTER_PROJECT_ID: Die Cluster-Projekt-ID

Beachten Sie, dass --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE dem älteren Flag --enable-binauthz entspricht.

Richtlinie löschen

Führen Sie den folgenden Befehl aus, um die Richtlinie zu löschen. Die prüfbasierte Plattformrichtlinie muss nicht gelöscht werden, um die prüfbasierte Richtlinienprüfung zu deaktivieren.

gcloud beta container binauthz policy delete POLICY_ID \
    --platform=gke \
    --project="POLICY_PROJECT_ID"

Ersetzen Sie Folgendes:

  • POLICY_ID: Die ID der Richtlinie
  • POLICY_PROJECT_ID: Die Richtlinien-Projekt-ID

Nächste Schritte