Sigstore-Signaturprüfung verwenden

Auf dieser Seite erfahren Sie, wie Sie die Sigstore-Signaturprüfung für die kontinuierliche Validierung (Continuous Validation, CV) der Binärautorisierung verwenden. Die Prüfung verifiziert die von Sigstore generierten Signaturen 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. Der Hauptunterschied zwischen dieser Prüfung und der einfachen Prüfung auf Attestierungsignatur besteht darin, dass der Sigstore-Signaturworkflow keine Artefaktanalyse-Hinweise verwendet, um Signaturen mit Images zu verknüpfen. Alle Signaturen werden zusammen mit dem Bild gespeichert, das sie signieren.

Diese Prüfung unterstützt nur Artifact Registry-Repositories.

Kosten

In diesem Leitfaden werden folgende Google Cloud-Dienste verwendet.

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

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

Hinweise

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.

Install the Google Cloud CLI.

To initialize the gcloud CLI, run the following command:

gcloud init

Note: If you installed the gcloud CLI previously, make sure you have the latest version by running

gcloud components
      update

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.

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

Enable the Binary Authorization, Cloud Key Management Service, Google Kubernetes Engine, Artifact Registry APIs:

gcloud services enable binaryauthorization.googleapis.com cloudkms.googleapis.com container.googleapis.com artifactregistry.googleapis.com

Install the Google Cloud CLI.

To initialize the gcloud CLI, run the following command:

gcloud init

Note: If you installed the gcloud CLI previously, make sure you have the latest version by running

gcloud components
      update

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.

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

Enable the Binary Authorization, Cloud Key Management Service, Google Kubernetes Engine, Artifact Registry APIs:

gcloud services enable binaryauthorization.googleapis.com cloudkms.googleapis.com container.googleapis.com artifactregistry.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.
Installieren Sie das cosign-Befehlszeilentool

Erforderliche Rollen

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

Übersicht

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-Sigstore-Signaturprüfung 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 von Ihrem 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
Wenn sich Ihr Image-Repository-Projekt von Ihrem Richtlinienprojekt unterscheidet: Artifact Registry-Leser (roles/artifactregistry.reader) für den Dienst-Agent für Binärautorisierungen des Richtlinienprojekts

Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen 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 zum Auswerten der CV-Sigstore-Signaturprüfung hat, müssen Sie dem Dienst-Agent für die Binärautorisierung in jedem Projekt die folgenden IAM-Rollen zuweisen.

Gewähren Sie dem Dienst-Agent für den Binärautorisierungsdienst 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.
Gewähren Sie dem Dienst-Agent für die Binärautorisierung des Richtlinienprojekts Zugriff auf die Signaturen in Ihrem Repository:
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 REPOSITORY_PROJECT_ID \
    --member="serviceAccount:$SERVICE_ACCOUNT" \
    --role='roles/artifactregistry.reader'
```
  Ersetzen Sie REPOSITORY_PROJECT_ID durch die ID des Projekts, das Ihr Repository 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 die 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 (Cloud KMS) oder lokale Schlüssel verwenden. Wir empfehlen jedoch, für die Produktion Cloud KMS-Schlüssel zu verwenden.

PKIX Cloud KMS Cosign

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
Generieren Sie den Schlüssel mit der Cosign-Befehlszeile:
```
cosign generate-key-pair \
  --kms gcpkms://projects/${KMS_KEY_PROJECT_ID}/locations/${KMS_KEY_LOCATION}/keyRings/${KMS_KEYRING_NAME}/cryptoKeys/${KMS_KEY_NAME}
```
Hinweis: Möglicherweise müssen Sie den Befehl gcloud auth application-default login ausführen, um Ihre Anmeldedaten richtig zu konfigurieren.
Notieren Sie sich den Speicherort des öffentlichen Schlüssels:

Cosign speichert den generierten öffentlichen Schlüssel automatisch als cosign.pub im Verzeichnis, in dem der Befehl generate-key-pair ausgeführt wurde. Speichern Sie diesen Dateispeicherort in einer Variablen für zukünftige Befehle.
```
PUBLIC_KEY_FILE="$(pwd)/cosign.pub"
```

PKIX Cloud KMS gcloud

So erstellen Sie das Schlüsselpaar in Cloud KMS:

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

Erstellen Sie den Schlüsselbund:

gcloud kms keyrings create ${KMS_KEYRING_NAME} \
    --location=${KMS_KEY_LOCATION} \
    --project=${KMS_KEY_PROJECT_ID}

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}

Exportieren Sie das Material des öffentlichen Schlüssels in eine Datei:

PUBLIC_KEY_FILE="$(pwd)/cosign.pub"
gcloud kms keys versions get-public-key 1 \
    --key=${KMS_KEY_NAME} \
    --keyring=${KMS_KEYRING_NAME} \
    --location=${KMS_KEY_LOCATION} \
    --output-file=${PUBLIC_KEY_FILE} \
    --project=${KMS_KEY_PROJECT_ID}

Lokaler Schlüssel

So erstellen Sie das Schlüsselpaar lokal:

  cosign generate-key-pair
  PUBLIC_KEY_FILE="$(pwd)/cosign.pub"
  PRIVATE_KEY_FILE="$(pwd)/cosign.key"

Plattformrichtlinie erstellen

So erstellen Sie die CV-Plattformrichtlinie mit einer Sigstore-Signaturprüfung:

Erstellen Sie die Plattformrichtliniendatei für die Sigstore-Signaturprüfung:

cat > POLICY_PATH <<EOF
gkePolicy:
  checkSets:
  - checks:
    - displayName: sigstore-signature-check
      sigstoreSignatureCheck:
        sigstoreAuthorities:
        - displayName: sigstore-authority
          publicKeySet:
            publicKeys:
              publicKeyPem: |
$(awk '{printf "                %s\n", $0}' ${PUBLIC_KEY_FILE})
EOF

Ersetzen Sie POLICY_PATH durch den Pfad zur Richtliniendatei.

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

Test-CV

In diesem Abschnitt testen Sie CV, indem Sie ein signiertes Image bereitstellen. In diesem Fall wird die Signatur durch die Sigstore-Signaturprüfung im CV verifiziert und es wird kein Logeintrag erstellt.

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

Image signieren

Damit die Überprüfung erfolgreich ist, muss das Bild eine gültige Signatur haben. So erstellen Sie die Signatur:

Erstellen Sie die Variablen, mit denen Sie das Image signieren:
```
IMAGE_PATH=IMAGE_PATH
IMAGE_DIGEST=sha256:IMAGE_DIGEST_SHA
IMAGE_TO_SIGN="${IMAGE_PATH}@${IMAGE_DIGEST}"
```
Ersetzen Sie Folgendes:
- IMAGE_PATH: Pfad zum Bild
- IMAGE_DIGEST_SHA: SHA-Hash des Digests Ihres Bildes
Unterzeichnen Sie das Image und übertragen Sie die Signatur per Push in die Artifact Registry:
PKIX Cloud KMS
Signieren Sie das Image mit einem in Cloud KMS gehosteten Schlüssel und pushen Sie die Signatur in Artifact Registry:
```
cosign sign \
    --key gcpkms://projects/${KMS_KEY_PROJECT_ID}/locations/${KMS_KEY_LOCATION}/keyRings/${KMS_KEYRING_NAME}/cryptoKeys/${KMS_KEY_NAME} \
    ${IMAGE_TO_SIGN}
```
Lokaler Schlüssel
Signieren Sie das Image mit einem lokalen privaten Schlüssel und übertragen Sie die Signatur per Push in Artifact Registry.
```
cosign sign --key ${PRIVATE_KEY_FILE} ${IMAGE_TO_SIGN}
```
Auf Prompt für Cosignatur antworten:

Nachdem Sie den Befehl cosign sign ausgeführt haben, werden Sie von Cosign gefragt, ob Sie die Signatur in den Transparenzprotokoll-Eintrag hochladen möchten. Beantworten Sie die Prompts mit y oder n. Weitere Informationen zu Rekor finden Sie in der Rekor-Dokumentation.

Signatur manuell bestätigen

So überprüfen Sie die Signatur manuell:

Prüfen Sie, ob die Signatur in Artifact Registry vorhanden ist:

Google Cloud Console

Rufen Sie in der Google Cloud Console die Seite „Artifact Registry“ auf.

Zu Artifact Registry
Klicken Sie in der Liste der Repositories auf den Namen des Repositories, das Ihr Image enthält.
Klicken Sie auf den Namen des von Ihnen signierten Bilds.
Suchen Sie das Element mit der Unterschrift. Dieser Artikel hat das Tag: sha256-[image digest].sig. Es sollte nur ein Element mit dem Tag geben.
Klicken Sie auf Manifest.
Sie sollten eine JSON-Datei mit verschiedenen Feldern sehen. Jede Signatur befindet sich in einem Element der layers-Liste in der annotations-Zuordnung. Die Signaturen befinden sich unter dem Schlüssel dev.cosignproject.cosign/signature.

Hier ein Beispiel für ein Manifest:

  {
        "schemaVersion": 2,
        "mediaType": "application/vnd.oci.image.manifest.v1+json",
        "config": {
            "mediaType": "application/vnd.oci.image.config.v1+json",
            "size": SIZE_OF_LAYERS,
            "digest": "DIGEST_OF_LAYERS"
        },
        "layers": [
            {
                "mediaType": "application/vnd.dev.cosign.simplesigning.v1+json",
                "size": SIZE_OF_ANNOTATIONS,
                "digest": "DIGEST_OF_ANNOTATIONS",
                "annotations": {
                    "dev.cosignproject.cosign/signature": "BASE64_SIGNATURE",
                    "dev.sigstore.cosign/bundle": "BUNDLE"
                }
            }
        ]
  }

Das Beispielmanifest enthält Folgendes:

SIZE_OF_LAYERS: Größe des layers-Arrays in Byte
DIGEST_OF_LAYERS: der Digest des layers-Arrays
SIZE_OF_ANNOTATIONS: Größe des annotations-Wörterbuchs in Byte
DIGEST_OF_ANNOTATIONS: Digest des Wörterbuchs annotations
BASE64_SIGNATURE: Die Rohsignatur im Base64-Format. Das ist die Signatur, die für die Bestätigung verwendet wird.
BUNDLE: Sigstore-spezifische Metadaten

Weitere Informationen zum Manifestformat finden Sie in der Cosignaturspezifikation von Sigstore.

Befehlszeile

Suchen Sie das richtige Artefakt:

Liste der mit dem Bild gespeicherten Elemente aufrufen:

gcloud artifacts docker tags list ${IMAGE_PATH}

Eine Beispielausgabe sieht so aus:

Listing items under project PROJECT_ID, location REPOSITORY_LOCATION, repository REPOSITORY_NAME.
TAG                         IMAGE                                                         DIGEST
latest                      us-east1-docker.pkg.dev/my-project/my-repo/my-image           sha256:abc123
sha256-abc123.sig           us-east1-docker.pkg.dev/my-project/my-repo/my-image           sha256:def456

In der Ausgabe enthält das Artefakt mit dem Tag sha256-abc123.sig die Signatur in seinem Manifest.

Manifest abrufen

Führen Sie den folgenden Befehl aus, um das Manifest des Artefakts mit dem Tag sha256-IMAGE_DIGEST_SHA.sig abzurufen:

curl -X GET -H "Content-Type: application/json" \
            -H "Authorization: Bearer $(gcloud auth print-access-token)" \
            -H "X-Goog-User-Project: REPOSITORY_PROJECT_ID" \
            "https://REPOSITORY_LOCATION-docker.pkg.dev/v2/REPOSITORY_PROJECT_ID/REPOSITORY_NAME/IMAGE_NAME/manifests/sha256-IMAGE_DIGEST_SHA.sig"

Ersetzen Sie Folgendes:

REPOSITORY_PROJECT_ID: Die ID des Projekts, das das Repository enthält
REPOSITORY_LOCATION: Speicherort des Repositorys
REPOSITORY_NAME: Name des Repositorys.
IMAGE_NAME: der Name des Image

Sie sollten eine JSON-Datei mit verschiedenen Feldern sehen. Jede Signatur befindet sich in einem Element der layers-Liste in der annotations-Zuordnung. Die Signaturen befinden sich unter dem Schlüssel dev.cosignproject.cosign/signature.

Hier ein Beispiel für ein Manifest:

{
    "schemaVersion": 2,
    "mediaType": "application/vnd.oci.image.manifest.v1+json",
    "config": {
        "mediaType": "application/vnd.oci.image.config.v1+json",
        "size": SIZE_OF_LAYERS,
        "digest": "DIGEST_OF_LAYERS"
    },
    "layers": [
        {
            "mediaType": "application/vnd.dev.cosign.simplesigning.v1+json",
            "size": SIZE_OF_ANNOTATIONS,
            "digest": "DIGEST_OF_ANNOTATIONS",
            "annotations": {
                "dev.cosignproject.cosign/signature": "BASE64_SIGNATURE",
                "dev.sigstore.cosign/bundle": "BUNDLE"
            }
        }
    ]
}

Das Beispielmanifest enthält Folgendes:

SIZE_OF_LAYERS: Größe des layers-Arrays in Byte
DIGEST_OF_LAYERS: der Digest des layers-Arrays
SIZE_OF_ANNOTATIONS: Größe des annotations-Wörterbuchs in Byte
DIGEST_OF_ANNOTATIONS: Digest des Wörterbuchs annotations
BASE64_SIGNATURE: Die Rohsignatur im Base64-Format. Das ist die Signatur, die für die Bestätigung verwendet wird.
BUNDLE: Sigstore-spezifische Metadaten

Weitere Informationen zum Manifestformat finden Sie in der Cosignaturspezifikation von Sigstore.

Signatur manuell bestätigen:

Verwende cosign verify, um die hochgeladene Signatur zu prüfen:
PKIX Cloud KMS
```
cosign verify --key gcpkms://projects/${KMS_KEY_PROJECT_ID}/locations/${KMS_KEY_LOCATION}/keyRings/${KMS_KEYRING_NAME}/cryptoKeys/${KMS_KEY_NAME} \
      ${IMAGE_PATH}@${IMAGE_DIGEST}
```
Lokaler Schlüssel
```
cosign verify --key {PUBLIC_KEY_FILE} ${IMAGE_PATH}@${IMAGE_DIGEST}
```
Hinweis: Je nachdem, ob Sie die Signatur in das öffentliche Transparenzlog Rekor hochgeladen haben, müssen Sie möglicherweise das Befehlszeilen-Flag --insecure-ignore-tlog der Reihe nach hinzufügen, um die Signatur zu prüfen.

Wenn die Überprüfung erfolgreich war, wird in der Befehlsausgabe The signatures were verified against the specified public key angezeigt.

Signiertes Image bereitstellen

So stellen Sie ein signiertes Image bereit:

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 ein Image bereit und prüfen Sie die Bereitstellung anhand der Richtlinie für die Binärautorisierung:
```
kubectl run hello-app-signed --image=${IMAGE_PATH}@${IMAGE_DIGEST}
```
Der Pod wurde bereitgestellt. Da das Image signiert ist, erzeugt CV keine Logeinträge zu diesem Pod.

Hinweis: Wenn bei der Bereitstellung Fehler auftreten, müssen Sie dem Compute Engine-Dienstagenten möglicherweise die Berechtigung zum Zugriff auf das Repository erteilen. Weitere Informationen finden Sie in der Google Cloud SDK-Dokumentation.

Unbeschriebenes Image bereitstellen

In diesem Abschnitt stellen Sie ein nicht signiertes Image bereit.

Da die Richtlinie Signaturen 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-unsigned \
      --image=UNSIGNED_IMAGE_PATH@UNSIGNED_IMAGE_DIGEST

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

Sie können in Cloud Logging-Einträgen nach CV-Konfigurationsfehlern und Verstößen gegen die CV-Plattformrichtlinien suchen.

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

Logs zu CV-Konfigurationsfehlern aufrufen

Führen Sie den folgenden Befehl aus, um Fehlerprotokolle für die CV-Konfiguration aufzurufen:

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

Die folgende Ausgabe zeigt einen Konfigurationsfehler, bei dem keine CV-Plattformrichtlinie gefunden wird:

{
  "insertId": "141d4f10-72ea-4a43-b3ec-a03da623de42",
  "jsonPayload": {
    "@type": "type.googleapis.com/google.cloud.binaryauthorization.v1beta1.ContinuousValidationEvent",
    "configErrorEvent": {
      "description": "Cannot monitor cluster 'us-central1-c.my-cluster': Resource projects/123456789/platforms/gke/policies/my-policy does not exist."
    }
  },
  "resource": {
    "type": "k8s_cluster",
    "labels": {
      "cluster_name": "my-cluster",
      "location": "us-central1-c",
      "project_id": "my-project"
    }
  },
  "timestamp": "2024-05-28T15:31:03.999566Z",
  "severity": "WARNING",
  "logName": "projects/my-project/logs/binaryauthorization.googleapis.com%2Fcontinuous_validation",
  "receiveTimestamp": "2024-05-28T16:30:56.304108670Z"
}

Validierungsverstöße gegen CV-Plattformrichtlinien ansehen

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

Sigstore-Signaturprüfung verwenden

Kosten

Hinweise

Erforderliche Rollen

Übersicht

Rollen mit der gcloud CLI gewähren

Ein Schlüsselpaar erstellen

PKIX Cloud KMS Cosign

PKIX Cloud KMS gcloud

Lokaler Schlüssel

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)

Test-CV

Image signieren

PKIX Cloud KMS

Lokaler Schlüssel

Signatur manuell bestätigen

Google Cloud Console

Befehlszeile

PKIX Cloud KMS

Lokaler Schlüssel

Signiertes Image bereitstellen

Unbeschriebenes Image bereitstellen

Logs für CV-Einträge ansehen

Logs zu CV-Konfigurationsfehlern aufrufen

Validierungsverstöße gegen CV-Plattformrichtlinien 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