SLSA-Prüfung verwenden

Auf dieser Seite erfahren Sie, wie Sie mit der CV-SLSA-Prüfung (Continuous Validation) für die Binärautorisierung die SLSA-konforme Herkunft von Container-Images prüfen, die mit auf GKE-Clustern (Google Kubernetes Engine) ausgeführten Pods verknüpft sind, für die CV aktiviert ist.

Für diese Prüfung müssen Sie Images mit Cloud Build erstellen, um eine SLSA-konforme Herkunft zu erzeugen.

Im Beispiel in dieser Anleitung werden Cloud Source Repositories für das Quellcode-Repository, Artifact Registry für die Image-Registry und Cloud Build verwendet, um das Image zu erstellen und die Herkunft zu erzeugen.

Der einzige vertrauenswürdige Builder, den die SLSA-Prüfung unterstützt, ist Cloud Build.

Kosten

In diesem Leitfaden werden folgende Google Cloud-Dienste verwendet.

Artifact Registry
Binärautorisierung, aber CV ist in der Vorschauphase kostenlos.
Cloud Build
Cloud Source Repositories
GKE

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

Hinweise

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.

Installieren Sie die Google Cloud CLI.

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

gcloud init

Hinweis: Wenn Sie die gcloud CLI zuvor installiert haben, prüfen Sie, ob Sie die neueste Version haben, indem Sie

gcloud components
      update

ausführen.

Google Cloud-Projekt erstellen oder auswählen.

Erstellen Sie ein Google Cloud-Projekt:
```
gcloud projects create PROJECT_ID
```
Ersetzen Sie PROJECT_ID durch einen Namen für das Google Cloud-Projekt, das Sie erstellen.
Wählen Sie das von Ihnen erstellte Google Cloud-Projekt aus:
```
gcloud config set project PROJECT_ID
```
Ersetzen Sie PROJECT_ID durch den Namen Ihres Google Cloud-Projekts.

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

Aktivieren Sie die Artifact Registry, Binary Authorization, Cloud Build, GKE, Cloud Source Repositories APIs:

gcloud services enable artifactregistry.googleapis.com binaryauthorization.googleapis.com cloudbuild.googleapis.com container.googleapis.com sourcerepo.googleapis.com

Installieren Sie die Google Cloud CLI.

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

gcloud init

Hinweis: Wenn Sie die gcloud CLI zuvor installiert haben, prüfen Sie, ob Sie die neueste Version haben, indem Sie

gcloud components
      update

ausführen.

Google Cloud-Projekt erstellen oder auswählen.

Erstellen Sie ein Google Cloud-Projekt:
```
gcloud projects create PROJECT_ID
```
Ersetzen Sie PROJECT_ID durch einen Namen für das Google Cloud-Projekt, das Sie erstellen.
Wählen Sie das von Ihnen erstellte Google Cloud-Projekt aus:
```
gcloud config set project PROJECT_ID
```
Ersetzen Sie PROJECT_ID durch den Namen Ihres Google Cloud-Projekts.

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

Aktivieren Sie die Artifact Registry, Binary Authorization, Cloud Build, GKE, Cloud Source Repositories APIs:

gcloud services enable artifactregistry.googleapis.com binaryauthorization.googleapis.com cloudbuild.googleapis.com container.googleapis.com sourcerepo.googleapis.com

Prüfen Sie, ob die gcloud CLI auf die neueste Version aktualisiert ist.
Installieren Sie das kubectl-Befehlszeilentool
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 CV-SLSA-Prüfung hat, bitten Sie Ihren Administrator, dem Dienst-Agent für die Binärautorisierung in jedem Projekt die folgenden IAM-Rollen zu gewähren:

Artifact Registry-Leser (roles/artifactregistry.reader) für das Compute Engine-Dienstkonto des Clusterprojekts
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 die Dienstkonten in jedem Projekt die erforderlichen Berechtigungen zum Auswerten dieser Prüfung haben, erteilen Sie den Dienstkonten in jedem Projekt die folgenden IAM-Rollen:

Wenn sich das Projekt, in dem Sie den Cluster ausführen, von dem Projekt unterscheidet, in dem sich die Richtlinie befindet, müssen Sie dem Dienst-Agent für die Binärautorisierung des Clusterprojekts die Berechtigung erteilen, 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.

Gewähren Sie dem Dienst-Agent des Richtlinienprojekts Zugriff auf Attestierungen:

Rufen Sie den Dienst-Agent für die Binärautorisierung ab, der dem Richtlinienprojekt zugeordnet ist:

PROJECT_NUMBER=$(gcloud projects list \
  --filter="projectId:POLICY_PROJECT_ID" \
  --format="value(PROJECT_NUMBER)")
POLICY_PROJECT_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.

Weisen Sie die Rolle zu:

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

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

Gewähren Sie dem Compute Engine-Standarddienstkonto die Berechtigung, das Image aus dem Repository abzurufen:
1. Rufen Sie das Compute Engine-Dienstkonto ab, das dem Clusterprojekt zugeordnet ist:
```
PROJECT_NUMBER=$(gcloud projects list \
  --filter="projectId:CLUSTER_PROJECT_ID" \
  --format="value(PROJECT_NUMBER)")
COMPUTE_ENGINE_SERVICE_ACCOUNT="$PROJECT_NUMBER-compute@developer.gserviceaccount.com"
```
  Ersetzen Sie CLUSTER_PROJECT_ID durch die ID des Cluster-Projekts, das Ihre Richtlinie enthält.
2. Weisen Sie die Rolle zu:
```
gcloud projects add-iam-policy-binding ARTIFACT_PROJECT_ID \
    --member="serviceAccount:$COMPUTE_ENGINE_SERVICE_ACCOUNT" \
    --role='roles/artifactregistry.reader'
```
  Ersetzen Sie dabei ARTIFACT_PROJECT_ID durch die ID des Artifact Registry-Projekts, das die bereitzustellenden Images hostet.

Optional: Beispiel-Image erstellen und hochladen

Dieser Abschnitt dient zur Veranschaulichung und zeigt Ihnen, wie Sie ein einfaches Beispiel-Image mit SLSA-konformer Herkunft erstellen. Die Herkunft wird später in der Anleitung verwendet, um die Prüfung zu demonstrieren. Weitere Informationen zur Cloud Build-Herkunft

Beispiel-Repository erstellen

So erstellen Sie ein Repository in Cloud Source Repositories:

Erstellen Sie das Repository und klonen Sie es lokal:
```
gcloud source repos create SOURCE_REPO_NAME \
    --project=SOURCE_REPO_PROJECT_ID && \
gcloud source repos clone SOURCE_REPO_NAME \
    --project=SOURCE_REPO_PROJECT_ID && \
cd SOURCE_REPO_NAME
```
Ersetzen Sie Folgendes:
- SOURCE_REPO_NAME: der Name Ihres Quellcode-Repositorys, z. B. slsa-check-test-repo
- SOURCE_REPO_PROJECT_ID: die Projekt-ID des Repositorys
So erstellen Sie die Quell-, Konfigurations- und Build-Dateien:
1. Erstellen Sie die Image-Quelle:
```
cat > quickstart.sh <<EOF
#!/bin/sh
echo "Hello, world! The time is $(date)."
sleep infinity
EOF
```
2. Machen Sie die Datei ausführbar:
```
chmod +x quickstart.sh
```
3. Erstellen Sie die Dockerfile-Konfigurationsdatei:
```
cat > Dockerfile <<EOF
FROM alpine
COPY quickstart.sh /
CMD ["/quickstart.sh"]
EOF
```
4. Erstellen Sie die Cloud Build-Datei cloudbuild.yaml, die das Image per Push an Artifact Registry überträgt:
```
cat > cloudbuild.yaml <<EOF
steps:
- name: 'gcr.io/cloud-builders/docker'
  args: [ 'build', '-t', 'LOCATION-docker.pkg.dev/ARTIFACT_PROJECT_ID/ARTIFACT_REPO_NAME/DIRECTORY/IMAGE', '.' ]
options:
  requestedVerifyOption: VERIFIED
images:
- 'LOCATION-docker.pkg.dev/ARTIFACT_PROJECT_ID/ARTIFACT_REPO_NAME/DIRECTORY/IMAGE'
EOF
```
  Ersetzen Sie Folgendes:
  - LOCATION: Artifact Registry-Standort, z. B. us-west2, europe-central2 oder asia-east1
  - ARTIFACT_PROJECT_ID: die ID des Projekts, in dem Artifact Registry-Artefakte gespeichert sind
  - ARTIFACT_REPO_NAME: der Name des Artifact Registry-Repositorys, z. B. slsa-check-test-repo
  - DIRECTORY: das Verzeichnis, z. B. slsa-check
  - IMAGE: der Pfad zum Image, z. B. slsa-check-image
5. Übertragen Sie die Dateien per Commit an Cloud Source Repositories:
```
git add .
git commit -a
```

Beispiel-Image erstellen und hochladen

Zur Vereinfachung dieser Anleitung empfehlen wir die Verwendung desselben Projekts für SOURCE_REPO_PROJECT_ID und ARTIFACT_PROJECT_ID. Wenn Sie andere Projekte verwenden, müssen Sie möglicherweise zusätzliche IAM-Berechtigungen einrichten. Weitere Informationen zur Zugriffssteuerung in Artifact Registry Weitere Informationen zu Cloud Build finden Sie unter Cloud Build – Übersicht.

So erstellen Sie das Repository:

Erstellen Sie das Artifact Registry-Repository:
```
gcloud artifacts repositories create ARTIFACT_REPO_NAME \
    --project=ARTIFACT_PROJECT_ID \
    --repository-format=docker \
    --location=LOCATION \
    --description="Docker repository"
```
Ersetzen Sie Folgendes:
- ARTIFACT_REPO_NAME: der Name Ihres Repositorys
- ARTIFACT_PROJECT_ID: die Projekt-ID des Artefakts
- LOCATION: Artifact Registry-Standort, z. B. us-west2, europe-central2 oder asia-east1

Erstellen Sie den Cloud Build-Trigger:

gcloud beta builds triggers create cloud-source-repositories \
    --project=SOURCE_REPO_PROJECT_ID \
    --repo=SOURCE_REPO_NAME \
    --region=LOCATION \
    --branch-pattern=.* \
    --build-config=cloudbuild.yaml

Ersetzen Sie Folgendes:

SOURCE_REPO_NAME: der Name des Quellcode-Repositorys
SOURCE_REPO_PROJECT_ID: die ID des Cloud Build-Projekts
LOCATION: der Standort

Lösen Sie einen Build aus, indem Sie die Dateien übertragen, die Sie zuvor in dieser Anleitung erstellt haben.
```
git push
```
Wenn das Image erfolgreich erstellt wird, generiert Cloud Build die Herkunft und lädt das Image in Ihr Artifact Registry-Repository hoch.
So suchen Sie nach dem neuesten Image und rufen seinen Digest ab:
1. Prüfen Sie, ob Cloud Build Ihr Image erstellt hat:
```
gcloud artifacts docker images list LOCATION-docker.pkg.dev/ARTIFACT_PROJECT_ID/REPO_NAME/DIRECTORY \
    --project=ARTIFACT_PROJECT_ID \
    --sort-by=create_time
```
  Ersetzen Sie Folgendes:
  - LOCATION: Artifact Registry-Standort
  - ARTIFACT_PROJECT_ID: die Projekt-ID für Artefakte
  - ARTIFACT_REPO_NAME: der Name des Repositorys
  - DIRECTORY: das Verzeichnis
2. Kopieren Sie den Digest des neuesten Images. Der Digest sieht dann ungefähr so aus: sha256:9432f747bd058b33de33bb5314d6eec1ac357d664e04c76824bb7072a9218d59

Optional: Sehen Sie sich die Herkunft Ihres Images an:

gcloud artifacts docker images describe \
  LOCATION-docker.pkg.dev/ARTIFACT_PROJECT_ID/ARTIFACT_REPO_NAME/DIRECTORY/IMAGE@DIGEST \
    --project=ARTIFACT_PROJECT_ID \
    --show-provenance

Ersetzen Sie Folgendes:

ARTIFACT_PROJECT_ID: die Projekt-ID für Artefakte
LOCATION: Artifact Registry-Standort
ARTIFACT_REPO_NAME: der Name des Artefakt-Repositorys
DIRECTORY: das Verzeichnis
IMAGE: der Pfad zum Image
DIGEST: der mit dem Image verknüpfte Digest

Die Befehlsausgabe sieht dann ungefähr so aus:

image_summary:
  digest: sha256:9432f747bd058b33de33bb5314d6eec1ac357d664e04c76824bb7072a9218d59
  fully_qualified_digest: us-west2-docker.pkg.dev/my-project/slsa-check-repo/slsa-check-image@sha256:9432f747bd058b33de33bb5314d6eec1ac357d664e04c76824bb7072a9218d59
  registry: us-west2-docker.pkg.dev
  repository: slsa-check-repo
  slsa_build_level: 3
provenance_summary:
  provenance:
  - build:
      intotoStatement:
        _type: https://in-toto.io/Statement/v0.1
        predicateType: https://slsa.dev/provenance/v0.1
        slsaProvenance:
          builder:
            id: https://cloudbuild.googleapis.com/GoogleHostedWorker
          materials:
          - digest:
              sha1: de4e4227fff1d00d6f7785a827608627e4a369ea
            uri: git+https://source.cloud.google.com/my-project/slsa-check-source-repo
          metadata:
            ...
envelope:
  payload: eyJfdHlwZSI6I ... taW1hZ2U6dGFnMSJ9XX0=
  payloadType: application/vnd.in-toto+json
  signatures:
  - keyid: projects/verified-builder/locations/global/keyRings/attestor/cryptoKeys/provenanceSigner/cryptoKeyVersions/1
    sig: MEQCIBCCkho_re4EfAT-NBSSmAXOZlv4lU_vWzEru97tU8KmAiAKcAa99umWngzNQADmPixqYjbKjLOKQEUvrI5chSrf7g==
  - keyid: projects/verified-builder/locations/global/keyRings/attestor/cryptoKeys/builtByGCB/cryptoKeyVersions/1
    sig: MEUCIFOEq_7RpiZAB4vUlit3hkZ2yI0n37-5Y87l0JbU-EZSAiEA9TNZZcv_MnzKffTnswHWZR2DSLmYiklr5twWfIec-zo=

Die Ausgabe muss den Block provenance_summary enthalten, damit die SLSA-Prüfung funktioniert. Wenn die Ausgabe nicht den Block enthält, prüfen Sie, ob Cloud Build von einem Build-Trigger aufgerufen wurde. Cloud Build erzeugt keine Herkunftsinformationen, wenn es manuell ausgelöst wird.

Eine Plattformrichtlinie erstellen

Zum Generieren der Herkunft müssen Sie einen Cloud Build-Trigger verwenden, um das Image zu erstellen, wie unter Beispiel-Image erstellen und hochladen beschrieben.

So erstellen Sie eine Plattformrichtlinie mit einer SLSA-Prüfung:

Erstellen Sie die YAML-Datei für die Plattformrichtlinie:
```
cat > POLICY_PATH <<EOF
gkePolicy:
  checkSets:
  - checks:
    - displayName: My SLSA check
      imageAllowlist:
        # This policy exempts images that are in the following artifact registry
        allowPattern:
        - ARTIFACT_LOCATION-docker.pkg.dev/ARTIFACT_PROJECT_ID/ARTIFACT_REPO_NAME/EXEMPT_IMAGE_PATH/**
      slsaCheck:
        rules:
        - attestationSource:
            containerAnalysisAttestationProjects:
            - projects/ATTESTATION_PROJECT_ID
          configBasedBuildRequired: true
          trustedBuilder: GOOGLE_CLOUD_BUILD
          trustedSourceRepoPatterns:
          - source.cloud.google.com/SOURCE_REPO_PROJECT_ID/SOURCE_REPO_NAME
    displayName: My check set
EOF
```
Ersetzen Sie Folgendes:
- POLICY_PATH: Ein Pfad für die Richtliniendatei.
- ARTIFACT_LOCATION: Der Speicherort Ihres Repositorys in Artifact Registry.
- ARTIFACT_PROJECT_ID: Die ID des Projekts, das Ihre Artefakte enthält.
- ARTIFACT_REPO_NAME: Das Repository, das das Image enthält.
- EXEMPT_IMAGE_PATH: Ein optionaler Pfad zu einem oder mehreren ausgenommenen Images, z. B. not-built-by-cloud-build. Der Block imageAllowlist ist in dieser Plattformrichtlinie enthalten, damit Sie Images ohne Herkunft ausschließen können, damit sie nicht gegen die Plattformrichtlinie verstoßen. Wenn Sie stattdessen Verstöße von diesen Images protokollieren möchten, lassen Sie diesen Block weg.
- ATTESTATION_PROJECT_ID: die Projekt-ID, die die von Cloud Build erstellten Attestierungen enthält.
- SOURCE_REPO_PROJECT_ID: die ID des Projekts, das Ihren Quellcode enthält.
- SOURCE_REPO_NAME: das Repository, das das Image enthält. Zur Veranschaulichung: Wenn Sie einen Verstoß gegen diese Prüfung erzwingen möchten, legen Sie SOURCE_REPO_NAME auf ein Quellcode-Repository fest, in dem sich das Image nicht befindet.
- POLICY_PROJECT_ID: Die ID des Projekts, das die CV-Richtlinie enthält.
- POLICY_ID: Die ID dieser Richtlinie.
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

Hinweis: Prüfen Sie, ob die Google Cloud CLI mit Authentifizierung und einem Projekt initialisiert wurde. Führen Sie dazu gcloud init oder gcloud auth login und gcloud config set project aus.
```
gcloud beta container binauthz policy create POLICY_ID \
    --platform=gke \
    --policy-file=POLICY_PATH \
    --project=POLICY_PROJECT_ID
```
Windows (PowerShell)

Hinweis: Prüfen Sie, ob die Google Cloud CLI mit Authentifizierung und einem Projekt initialisiert wurde. Führen Sie dazu gcloud init oder gcloud auth login und gcloud config set project aus.
```
gcloud beta container binauthz policy create POLICY_ID `
    --platform=gke `
    --policy-file=POLICY_PATH `
    --project=POLICY_PROJECT_ID
```
Windows (cmd.exe)

Hinweis: Prüfen Sie, ob die Google Cloud CLI mit Authentifizierung und einem Projekt initialisiert wurde. Führen Sie dazu gcloud init oder gcloud auth login und gcloud config set project aus.
```
gcloud beta container binauthz policy create POLICY_ID ^
    --platform=gke ^
    --policy-file=POLICY_PATH ^
    --project=POLICY_PROJECT_ID
```

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

Image bereitstellen

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
Stellen Sie den Pod bereit:
```
kubectl run hello-app \
    --image='LOCATION-docker.pkg.dev/ARTIFACT_PROJECT_ID/ARTIFACT_REPO_NAME/DIRECTORY/IMAGE@DIGEST'
```
Der Pod wird bereitgestellt. Da das Image mit Herkunft und einem vertrauenswürdigen Quellcode-Repository erstellt wurde, verstößt es nicht gegen die CV-SLSA-Prüfung und es werden keine Logeinträge generiert.

Wenn Sie einen Verstoß gegen die SLSA-Prüfung erzwingen möchten, können Sie SOURCE_REPO_NAME auf ein Quellcode-Repository festlegen, in dem sich das Image nicht befindet. Sie können den Build auch manuell auslösen, wodurch die Herkunftsgenerierung übersprungen wird. Suchen Sie dann nach Logeinträgen.

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

SLSA-Prüfung verwenden

Kosten

Hinweise

Erforderliche Rollen

Überblick

Rollen mit der gcloud CLI gewähren

Optional: Beispiel-Image erstellen und hochladen

Beispiel-Repository erstellen

Beispiel-Image erstellen und hochladen

Eine Plattformrichtlinie erstellen

Linux, macOS oder Cloud Shell

Windows (PowerShell)

Windows (cmd.exe)

CV aktivieren

Cluster erstellen, der das CV-Monitoring verwendet

Linux, macOS oder Cloud Shell

Windows (PowerShell)

Windows (cmd.exe)

Cluster mit Erzwingung und CV-Monitoring erstellen

Linux, macOS oder Cloud Shell

Windows (PowerShell)

Windows (cmd.exe)

Cluster zur Verwendung des CV-Monitoring aktualisieren

Linux, macOS oder Cloud Shell

Windows (PowerShell)

Windows (cmd.exe)

Cluster aktualisieren, um Erzwingung und CV-Monitoring zu verwenden

Linux, macOS oder Cloud Shell

Windows (PowerShell)

Windows (cmd.exe)

Image bereitstellen

Logs für CV-Einträge ansehen

Prüftypen

Beispiellog

Bereinigen

Binärautorisierung in einem Cluster deaktivieren

Prüfbasiertes Richtlinien-Monitoring in einem Cluster deaktivieren

Richtlinie löschen

Nächste Schritte