Kontinuierliche Validierung – Übersicht

Die kontinuierliche Validierung (Continuous Validation, CV) mit prüfbasierten Plattformrichtlinien ist eine Funktion der Binärautorisierung, mit der Sie Pods, die in Google Kubernetes Engine (GKE) ausgeführt werden, überwachen können, um sicherzustellen, dass die zugehörigen Container-Images weiterhin den Plattformrichtlinien für die Binärautorisierung die Sie angeben entsprechen.

Wenn die CV feststellt, dass Pods Plattformrichtlinien verletzen, werden die Verstöße in Cloud Logging protokolliert.

Die CV mit Plattformrichtlinien ersetzt die vorherige kontinuierliche Validierung (verworfen).

Vorteile der CV

Die Binärautorisierungserzwingung bietet eine einmalige Image-Validierung beim Bereitstellen von Container-Images. CV hingegen überwacht kontinuierlich, dass die mit ausgeführten Pods verknüpften Images Ihren Richtlinien entsprechen.

Aus diesem Grund können Sie, wenn Sie sowohl die Binärautorisierungserzwingung als auch die CV mit prüfbasierten Richtlinien aktivieren, dafür sorgen, dass die Richtlinienkonformität während des gesamten Orchestrierungslebenszyklus validiert wird.

Das CV ist in folgenden Szenarien nützlich:

Richtlinienänderungen: Wenn Sie die Projekt-Singleton-Erzwingungsrichtlinien für die Binärautorisierung aktualisieren, validiert die Binärautorisierung nur Images, die nach der Aktualisierung bereitgestellt werden. Pods, die bereits ausgeführt werden, sind davon nicht betroffen. Sie werden weiterhin ausgeführt, auch wenn die Binärautorisierung mit der aktualisierten Richtlinie jetzt das gleiche Image für die Bereitstellung blockieren würde.

Aus diesem Grund empfehlen wir beim Aktualisieren der Projekt-Singleton-Richtlinie für Binärautorisierung auch das Erstellen oder Aktualisieren einer CV-Plattformrichtlinie, die der Projekt-Singleton-Richtlinie entspricht. So informiert Sie CV über die Ausführung von Pods, die gegen Ihre aktualisierten Richtlinien verstoßen.
Image-Metadaten überwachen: CV bietet bestimmte Prüfungen auf Änderungen an Image-Metadaten, darunter:
- Attestierungen: CV-Logs, wenn die Attestierungen für die Images der Pods nicht mehr gültig sind.
- Aktualität: CV-Logs werden erkannt, wenn die Images von Pods nicht mehr aktuell sind.
- Herkunft: CV kann mithilfe von Build-Konfigurationen, die sich in einem vertrauenswürdigen Quell-Repository befinden, prüfen, ob die Images von Pods mit einem vertrauenswürdigen Builder erstellt wurden.
- Sigstore-Signaturen: CV erstellt einen Logeintrag, wenn die Images der Pods keine gültige Sigstore-Signatur haben.
- Vertrauenswürdiges Verzeichnis: CV erstellt einen Logeintrag, wenn sich die Images der Pods in einem Repository-Verzeichnis befinden, das nicht in Ihrer Plattformrichtlinie aufgeführt ist.
- Sicherheitslücken: CV erstellt einen Logeintrag, wenn Sicherheitslücken in den Images von Pods identifiziert werden.
Probelaufmonitoring: Wenn Sie den Probelauf aktivieren, ermöglicht die Binärautorisierung das Deployment aller Images. Durch das Aktivieren von CV mit einer Plattformrichtlinie, die Ihrer Projekt-Singleton-Richtlinie entspricht, protokolliert CV regelmäßig Images, die gegen die Plattformrichtlinie verstoßen.
Break-Glass-Monitoring: Wenn Sie Pods mit Break-Glass bereitstellen, umgeht die Binärautorisierung die Erzwingung der Projekt-Singleton-Richtlinie und protokolliert ein einzelnes Ereignis in Cloud-Audit-Logs. Mithilfe einer übereinstimmenden Plattformrichtlinie protokolliert CV jedoch weiterhin regelmäßig gegen Richtlinien verstoßende Pods, einschließlich Pods, die mit Break-Glass bereitgestellt werden.

Funktionsweise von CV

Sie müssen CV auf Ihren GKE-Clustern aktivieren, um es zu verwenden.

Nachdem Sie Images in Ihrem Cluster bereitgestellt haben, überwacht CV die zugehörigen Pods, um sicherzustellen, dass sie Ihrer prüfbasierten Plattformrichtlinie entsprechen.

CV unterstützt nur Image-Tags, die unter Ausgenommene Images angegeben sind.

CV prüft regelmäßig laufende Pods

Zum Monitoring laufender Pods prüft CV die mit jedem Pod verknüpften Images mindestens alle 24 Stunden. CV überwacht auch Init-Container.

Bei jeder Überprüfung ruft CV eine Liste der Images ab, die mit jedem Pod verknüpft sind. CV prüft dann, ob die Image-Informationen die Plattformrichtlinie erfüllen.

CV erfasst Verstöße gegen Plattformrichtlinien

Wenn die CV feststellt, dass Images gegen eine Plattformrichtlinie verstoßen, werden die Verstöße und andere Ergebnisse in Cloud Logging protokolliert. Für jede Plattformrichtlinie, gegen die verstoßen wird, wird für jeden Pod ein separater Logeintrag geschrieben.

Wenn CV die Images eines Pods mithilfe einer Plattformrichtlinie auswertet, erfüllen die Images möglicherweise einige Prüfungen und verstoßen gegen andere. Der CV erzeugt einen Logeintrag, wenn ein Image eines Pods gegen eine oder mehrere Prüfungen verstößt. Der Logeintrag enthält nur die Images, die gegen die Plattformrichtlinie verstoßen. Wenn alle Images alle Prüfungen erfüllen, werden keine Log-Einträge erstellt.

Bis ein Pod mit nicht richtlinienkonformen Images beendet wird, protokolliert CV weiterhin Richtlinienverstöße. Nicht richtlinienkonforme Pods, die während des Intervalls zwischen Prüfungen beendet werden, werden während der nächsten CV-Prüfung protokolliert.

CV beendet die ausgeführten Pods nicht.

CV verwendet eine Feedressource

Zum Abrufen von Informationen zu Pods, die auf Ihrem GKE-Cluster ausgeführt werden, erstellt CV eine Feedressource mit dem Namen binauthz-cv-cai-feed.

CV-Plattformrichtlinien

Zur Verwendung von CV konfigurieren Sie zuerst Plattformrichtlinien.

Plattformrichtlinien unterscheiden sich von Legacy-Richtlinien zur Binärautorisierung, die auch Projekt-Singleton-Richtlinien genannt werden. Das Bereitstellungsprojekt kann zwar nur eine Legacy-Projekt-Singleton-Richtlinie haben, aber Sie können mehrere Plattformrichtlinien konfigurieren. Jede Plattformrichtlinie kann sich in einem oder mehreren Projekten befinden.

Plattformrichtlinien funktionieren nur mit CV und unterstützen keine Erzwingung der Binärautorisierung. Wenn Sie die Erzwingung der Binärautorisierung und CV-Monitoring verwenden möchten, sollten Sie daher eine Projekt-Singleton-Richtlinie für die Erzwingung sowie eine Plattformrichtlinie für das Monitoring erstellen.

Angenommen, Sie möchten die Binärautorisierung so konfigurieren, dass eine Attestierung Ihrer Images erzwungen wird, bevor sie bereitgestellt werden können, und Sie möchten auch sicherstellen, dass die ausgeführten Pods mit dieser Anforderung konform sind. Dazu konfigurieren Sie eine Projekt-Singleton-Erzwingungsrichtlinie mit einem Attestierer. Anschließend erstellen Sie eine Plattformrichtlinie mit einer einfache Prüfung auf Attestierungsignatur, die einen Authentifikator enthält, der auf demselben Hinweis und öffentlichen Schlüssel wie der Attestierer basiert.

Plattformrichtlinien sind plattformspezifisch. GKE ist die einzige unterstützte Plattform.

Sie können Prüfungen in Plattformrichtlinien konfigurieren. Prüfungen werden in einem oder mehreren Prüfsätzen zusammengefasst. Für jeden Prüfsatz kann eine oder mehrere Prüfungen angegeben werden.

Plattformrichtlinien können Images von der Auswertung durch CV ausnehmen.

Erforderliche Berechtigungen

Zum Auflisten oder Beschreiben von Plattformrichtlinien benötigen Sie die Rolle binaryauthorization.policyViewer. Zum Erstellen, Ändern und Löschen von Plattformrichtlinien benötigen Sie die Rolle binaryauthorization.policyEditor. Weitere Informationen finden Sie unter Plattformrichtlinien verwalten.

Aktualisierungen von Richtlinien

Durch Aktualisieren einer Plattformrichtlinie wird die vorhandene Richtlinie mit einem Richtliniendeskriptor überschrieben, den Sie in der YAML-Datei angeben. Wenn Sie einer vorhandenen Plattformrichtlinie eine neue Prüfung hinzufügen möchten, empfehlen wir, die vorhandene Richtlinie zu beschreiben, in einer YAML-Datei zu speichern, die neue Prüfung hinzuzufügen und dann die Richtlinie mit der aktualisierten Datei zu aktualisieren.

Mehrere Plattformrichtlinien

Sie können Plattformrichtlinien im selben Projekt wie der Cluster (lokale Plattformrichtlinie) oder in einem anderen Projekt erstellen.

Da Sie eine Reihe von Plattformrichtlinien konfigurieren können, benennen Sie jede Richtlinie mit einem eindeutigen Ressourcennamen. Wenn Sie einen gcloud CLI-Befehl ausführen, verweisen Sie mit seiner ID auf die lokale Plattformrichtlinie. Wenn Sie auf eine Plattformrichtlinie in einem anderen Projekt verweisen, verwenden Sie den Ressourcennamen im folgenden Format: projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID

Sie können auswählen, welche Plattformrichtlinie mit jedem GKE-Cluster verknüpft werden soll. Dabei kann es sich um eine lokale Plattformrichtlinie oder eine Richtlinie in einem anderen Projekt handeln.

Mehrere Prüfungen pro Plattformrichtlinie

Sie können in jeder Plattformrichtlinie mehrere Prüfungen konfigurieren. Fügen Sie diese dazu dem Block checks der Richtlinie hinzu. Weitere Informationen zu bestimmten Prüfungen, die Sie konfigurieren können, finden Sie unter Prüfungen.

Wenn Ihre CV-Plattformrichtlinie mehr als eine Prüfung angibt, werden Images, die von einer Prüfung ausgewertet werden, weiterhin von den anderen Prüfungen ausgewertet.

Die Binärautorisierung wertet alle Prüfungen aus, die in der Plattformrichtlinie für jedes Image konfiguriert sind, es sei denn, das Image entspricht einem Muster für ausgenommene Images. Weitere Informationen finden Sie unter Ausgenommene Images.

Einzelprojekteinrichtung

Sie können CV in einem einzelnen Projekt einrichten.

In einer Einzelprojekteinrichtung werden die erforderlichen Rollen automatisch im Dienst-Agent für die Binärautorisierung eingerichtet.

Wenn sich GKE-Cluster, an die Cluster gebundene Plattformrichtlinien und die für Prüfungen erforderlichen Metadaten im selben Projekt befinden, sind keine zusätzlichen IAM-Rollen (Identity and Access Management) erforderlich.

Weitere Informationen zum Konfigurieren einer Einrichtung mit mehreren Projekten für zusätzliche Sicherheit finden Sie unter Trennung von Belangen.

Mehrere Projekte einrichten

Wenn Sie eine CV-Einrichtung mit mehreren Projekten mit Plattformrichtlinien konfigurieren, können sich die Plattformrichtlinien, die Images, der GKE-Cluster und andere Arten von CV-abhängigen Ressourcen jeweils in einem anderen Projekt befinden.

Bei der Einrichtung mit mehreren Projekten ist es wichtig, den Zweck jedes Projekts und der Ressourcen zu kennen, auf die CV zugreifen muss, und die erforderlichen IAM-Rollen und -Berechtigungen entsprechend einzurichten.

CV verwenden

So verwenden Sie CV:

Entscheiden Sie, welche Prüfungen Sie verwenden möchten.
Erstellen Sie eine oder mehrere Plattformrichtlinien mithilfe einer Richtlinien-YAML-Datei. Die Datei gibt an, welche Prüfungen Sie verwenden möchten.
Erstellen Sie die Plattformrichtlinie. Die Richtlinie kann in einem Projekt Ihrer Wahl gespeichert werden.
Wählen Sie aus, ob CV auf einzelnen Clustern oder in einer Flotte aktiviert werden soll.
Prüfen Sie CV-Logs in Logging auf Ereignisse.
Prüfen Sie die Logs und aktualisieren Sie Ihren Build und andere Prozesse so, dass Images erstellt werden, die die Prüfungen erfüllen.

Schecks

In diesem Abschnitt werden die spezifischen Prüfungen beschrieben, die CV bietet.

Prüfbasierte Richtlinien haben das folgende kanonische Format:

gkePolicy:
  checkSets:
  - checks:
    - CHECK_TYPE1:
        CHECK_TYPE1_PARAMETERS
      displayName: CHECK_TYPE1_DISPLAY_NAME
    - CHECK_TYPE2:
        CHECK_TYPE2_PARAMETERS
      displayName: CHECK_TYPE2_DISPLAY_NAME
    displayName: CHECK_SET_DISPLAY_NAME

Das Feld displayName in checks und checkSets ist optional. Es wird nur verwendet, wenn CV Richtlinienverletzungen erfasst. Er wird in einigen Beispielen weiter unten in dieser Anleitung weggelassen.

Always-Deny-Prüfung

Die Always-Deny-Prüfung sorgt dafür, dass alle Images, die dieser Prüfung unterliegen, fehlschlagen. Jedes Mal, wenn CV mit dieser Prüfung ausgeführte Pods überprüft, wird für jeden der Pods ein Logeintrag erstellt.

Sie können die Always-Deny-Prüfung mit Zulassungslisten oder mehreren Prüfsätzen kombinieren, damit die Binärautorisierung in bestimmten Fällen immer Logs für Pods erzeugt.

Wenn Sie die Prüfung immer ablehnen möchten, fügen Sie alwaysDeny: true im Block checks so hinzu:

gkePolicy:
  checkSets:
    - displayName: "My check set"
      checks:
        - alwaysDeny: true

Der Wert von alwaysDeny kann nicht auf false gesetzt werden. Entfernen Sie stattdessen das Häkchen.

Beispiele für die Verwendung der Always-Deny-Prüfung finden Sie unter Mehrere Prüfsätze verwenden.

Prüfung der Image-Aktualität

Die Prüfung der Image-Aktualität berechnet die Dauer, die ein Image ausgeführt wurde, und protokolliert, wenn die Dauer den Schwellenwert maxUploadAgeDays überschritten hat.

Im folgenden Beispiel für die Plattformrichtlinien-YAML protokolliert CV Pods mit Images, die in das Repository hochgeladen wurden, aus dem sie vor mehr als 30 Tagen bereitgestellt wurden.

gkePolicy:
  checkSets:
    checks:
    - imageFreshnessCheck:
        maxUploadAgeDays: 30
      displayName: "My image freshness check"
    displayName: "My check set"

Einfache Prüfung auf Attestierungsignatur

Mit der einfachen Prüfung für Attestierungsignatur können Sie prüfen, ob jedes Image des Pods eine gültige, signierte Attestierung hat.

Diese Prüfung entspricht der Attestierungsbewertung in einer Richtlinie zur Durchsetzung der Binärautorisierung. Sie können diese Prüfung mit denselben Hinweisen und Schlüsseln konfigurieren, die Sie für Ihren Attestierer verwendet haben. Wir empfehlen, diese Prüfung anstelle der kontinuierlichen Legacy-Validierung zu verwenden (verworfen).

Das folgende Beispiel zeigt eine Plattformrichtlinie mit einer einfachen Prüfung auf Attestierungsignatur:

gkePolicy:
  checkSets:
    checks:
      simpleSigningAttestationCheck:
        containerAnalysisAttestationProjects:
        - "projects/my-attestation-project1"
        - "projects/my-attestation-project2"
        attestationAuthenticators:
          pkixPublicKeySet:
            pkixPublicKeys:
              publicKeyPem: |
                -----BEGIN PUBLIC KEY-----
                MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQxXxgAEvgQuW1FHYZPB2PTQfOJKUkS9sjMO/1os10xOWrhl1kQo4EnzMOovROWVLo+m9mcwp7nRQ2qQDThZdSFi0nFJ1A==
                -----END PUBLIC KEY-----
              signatureAlgorithm: ECDSA_P256_SHA256

Anstelle von Attestierern von Binärautorisierungen haben CV-Attestierungsprüfungen Authentifikatoren. Authentifikatoren geben Sie direkt in der Richtlinie im Block attestationAuthenticators an.

In einer Plattformrichtlinie kann simpleSigningAttestationCheck mehrere attestationAuthenticators und mehrere Schlüssel in jedem pkixPublicKeySet haben. Die Prüfung ist erfolgreich, wenn für jedes Image der Pods eine gültige Attestierung vorliegt, die mit einem beliebigen Schlüssel in einem pkixPublicKeySet eines beliebigen Authentifikatoren signiert wurde.

CV-Plattformrichtlinien unterscheiden sich in folgenden Punkten von Projekt-Singleton-Richtlinien zur Erzwingung:

PGP-Schlüssel werden nicht unterstützt.
Attestierer werden nicht benötigt. Stattdessen erstellen Sie manuell Schlüssel und beschreiben dann eine Plattformrichtlinie, um die Schlüssel-ID abzurufen, die Sie dann zum Erstellen der Attestierung verwenden.
Sie erstellen und signieren die Nutzlast manuell, erstellen die JSON-Attestierungsdatei und dann die Attestierung mithilfe der Artifact Analysis API.
Sie erstellen weiterhin einen Artefaktanalyse-Hinweis, geben ihn jedoch nicht in der Richtlinie an. Stattdessen sucht CV in jedem Projekt, das im Feld containerAnalysisAttestationProjects aufgeführt ist, nach Attestierungen.
Attestierungen werden weiterhin in Artefaktanalyse-Vorkommen gespeichert, können jedoch in mehr als einem Projekt gespeichert werden.
Sie müssen mindestens ein Projekt, das Attestierungen enthält, explizit mit dem Ressourcennamen projects/ATTESTATION_PROJECT_ID angeben.

CV unterstützt nur Image-Tags, die unter "Ausgenommene Images" angegeben sind.

Wenn Images mit einem Image-Tag anstelle eines Digests bereitgestellt werden, wertet CV sie zuerst anhand von ausgenommenen Images aus, da Zulassungslisten Tags enthalten können. Wenn das Image nicht ausgenommen ist, versucht CV, den Image-Digest zu finden. Da es keinen gibt, verstößt das Image gegen die Prüfung.

SLSA-Prüfung

Die SLSA-Prüfung prüft die SLSA-spezifische Herkunft der Images von Pods.

Das folgende Beispiel zeigt eine YAML-Konfiguration für eine CV-Plattformrichtlinie:

gkePolicy:
  checkSets:
    checks:
      imageAllowlist:
        allowPattern: "gcr.io/my-images/not-built-by-GCB/**"
    - slsaCheck:
        rules:
          trustedBuilder: GOOGLE_CLOUD_BUILD
          attestationSource:
          - containerAnalysisAttestationProjects: "projects/attestation-project1"
          - containerAnalysisAttestationProjects: "projects/attestation-project2"
          # Require that images were built using a checked-in top-level config file.
          configBasedBuildRequired: true
          # Which repos the config file can be from.
          trustedSourceRepoPatterns:
          - "source.cloud.google.com/my-project/my-source-repo"
          - "github.com/my-github-user/*"
      displayName: "My SLSA check"
    displayName: "My check set"

Wenn CV Images mit dieser Plattformrichtlinie prüft, prüft es Folgendes:

Die Images müssen von einem vertrauenswürdigen Builder erstellt worden sein. Cloud Build ist der einzige vertrauenswürdige Builder, der von der SLSA-Prüfung unterstützt wird.
Cloud Build muss die Attestierungen entweder in attestation-project1 oder in attestation-project2 generiert haben.
Die Images müssen mit einer Konfigurationsdatei der obersten Ebene aus einem der folgenden vertrauenswürdigen Repositories erstellt werden:
- Das Repository source.cloud.google.com/my-project/my-source-repo/
- Alle Repositories in github.com/my-github-user/
Die Images in gcr.io/my-images/not-built-by-GCB/ oder den zugehörigen Unterverzeichnissen, die nicht von Cloud Build erstellt wurden, sind von der Prüfung ausgenommen, da sie dagegen verstoßen würden.

Sigstore-Signaturprüfung

Die Sigstore-Signaturprüfung verifiziert, ob Images mit Sigstore-Signaturen signiert wurden.

Diese Prüfung unterstützt nur Images, die in Artifact Registry gehostet werden. Sie prüft, ob eine aus Artifact Registry abgerufene Signatur erfolgreich mit einem Schlüssel in der Richtlinie verifiziert werden kann.

In der folgenden Beispielplattformrichtlinie wird beschrieben, wie Sie eine Sigstore-Signaturprüfung konfigurieren:

  gkePolicy:
    checkSets:
    - checks:
      - displayName: sigstore-signature-check
        sigstoreSignatureCheck:
          sigstoreAuthorities:
          - displayName: sigstore-authority
            publicKeySet:
              publicKeys:
                publicKeyPem: |
                  -----BEGIN PUBLIC KEY-----
                  MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQxXxgAEvgQuW1FHYZPB2PTQfOJKUkS9sjMO/1os10xOWrhl1kQo4EnzMOovROWVLo+m9mcwp7nRQ2qQDThZdSFi0nFJ1A==
                  -----END PUBLIC KEY-----

In der Plattformrichtlinie kann sigstoreSignatureCheck mehrere sigstoreAuthorities und mehrere Schlüssel in jedem publicKeySet haben. Die Prüfung ist erfolgreich, wenn für jedes Image der Pods eine gültige Attestierung vorliegt, die mit einem beliebigen Schlüssel in einem publicKeySet eines beliebigen Authentifikatoren signiert wurde.

Prüfung auf vertrauenswürdige Verzeichnisse

Bei der Prüfung auf vertrauenswürdige Verzeichnisse wird geprüft, ob sich die Images der Pods in einem der bereitgestellten vertrauenswürdigen Verzeichnisse befinden, die Sie in einer Plattformrichtlinie angeben.

Wenn Sie diese Prüfung verwenden, sollten Sie auch die Repositories, die Sie in Ihrer Richtlinie als vertrauenswürdige Verzeichnisse auflisten, vor unbefugtem Zugriff schützen.

In der folgenden Beispielplattformrichtlinie wird beschrieben, wie Sie eine Prüfung auf vertrauenswürdige Verzeichnisse konfigurieren:

gkePolicy:
  checkSets:
    checks:
      trustedDirectoryCheck:
        trustedDirPatterns:
        - "gcr.io/my-project/gcr-directory"
        - "us-central1-docker.pkg.dev/my-project/ar-directory"
        displayName: "My trusted directory check"
    displayName: "My check set"

In der Beispielplattformrichtlinie listet trustedDirPatterns die vertrauenswürdigen Verzeichnisse auf. Wenn sich alle Images der Pods in den aufgeführten Verzeichnissen befinden, entsprechen sie der Richtlinie. Pod-Images, die sich nicht in den aufgeführten Verzeichnissen befinden, verstoßen gegen die Richtlinie und CV protokolliert die Verstöße.

Prüfung auf Sicherheitslücken

Die Prüfung auf Sicherheitslücken verwendet Artifact Analysis, um zu prüfen, ob die Images der Pods Sicherheitslücken enthalten. Dazu gehören auch neue Sicherheitslücken, die seit der Bereitstellung des Pods auf Sicherheitslücken erkannt wurden. In der Prüfung auf Sicherheitslücken können Sie Schwellenwerte für den Schweregrad und bestimmte Sicherheitslücken (als CVEs) konfigurieren. Images mit Sicherheitslücken, die gegen die Prüfung auf Sicherheitslücken verstoßen, werden in Logging protokolliert.

Um diese Prüfung verwenden zu können, müssen Sie zuerst das Scannen auf Sicherheitslücken in Artifact Analysis aktivieren.

Die folgende Konfiguration der Plattformrichtlinie enthält eine Prüfung auf Sicherheitslücken:

gkePolicy:
  checkSets:
    - displayName: "Default check set"
      checks:
        - vulnerabilityCheck:
           maximumFixableSeverity: MEDIUM
           maximumUnfixableSeverity: HIGH
           allowedCves:
             - "CVE-2022-11111"
             - "CVE-2022-22222"
           blockedCves:
             - "CVE-2022-33333"
             - "CVE-2022-44444"
           containerAnalysisVulnerabilityProjects: "projects/my-project"

In diesem Beispiel definieren maximumUnfixableSeverity und maximumFixableSeverity allgemeine CVSS-Schweregrade (Common Vulnerability Scoring System), die mit einer Sicherheitslücke verknüpft sind, die von Artifact Analysis erkannt werden kann. Außerdem listet blockedCves bestimmte CVEs (Common Vulnerability Exposures) auf. Wenn eine erkannte Sicherheitslücke einen der angegebenen Schweregrade überschreitet oder mit einer der in blockedCves aufgeführten CVEs und mit keiner der in allowedCves aufgeführten CVEs übereinstimmt, dann erstellt CV einen Eintrag in Logging.

Aktualisierte Richtlinien validieren

Nachdem Sie eine CV-Plattformrichtlinie aktualisiert haben, sollten Sie dringend prüfen, ob die Binärautorisierung und CV weiterhin wie erwartet funktionieren.

Konfiguration validieren

Prüfen Sie Ihre Konfiguration sowohl anhand der Projekt-Singleton-Richtlinien für Binärautorisierungen als auch anhand der CV-Plattformrichtlinien.

Funktionsweise validieren

Wenn Sie prüfen möchten, ob die Binärautorisierung und CV wie erwartet funktionieren, können Sie Test-Pods bereitstellen und dann die Einträge der Binärautorisierung in Logging prüfen.

Images mit Zulassungslisten ausnehmen

Wenn Sie eine Plattformrichtlinie erstellen, können Sie Images von den Prüfungen ausnehmen, indem Sie deren URLs auf eine Zulassungsliste setzen. Eine Zulassungsliste auf Richtlinienebene schließt Images von der gesamten Richtlinie aus. Eine Zulassungsliste auf der Prüfsatzebene schließt Images nur vom Prüfsatz aus und gilt nur, wenn dieser Prüfsatz ausgewertet wird. Eine Zulassungsliste innerhalb eines Prüfsatzes schließt Images nur von dieser Prüfung aus.

Zulassungslistenmuster sind Muster, die einer oder mehreren Bild-URLs entsprechen. Ein Muster für Zulassungslisten kann eines der folgenden sein:

Ein Image-Namenspräfix, das mit dem Platzhalter * oder ** endet.
Nur ein Image-Name ohne Tag oder Digest.
Ein Image-Name mit einem Tag (oder Tag-Präfix mit dem Platzhalter *).
Ein Image-Name mit einem Digest.
Ein Image-Name mit einem Tag und einem Digest.

Im Folgenden finden Sie Beispiele für Muster der Zulassungsliste:

us-central1.pkg.dev/my-project/my-image:latest@sha256:77b0b75136b9bd0fd36fb50f4c92ae0dbdbbe164ab67885e736fa4374e0cbb8c entspricht einem genauen Image-Namen, einem Tag und einem Digest.
us-central1.pkg.dev/my-project/my-image:latest entspricht dem Namen und dem Tag, mit einem beliebigen Digest (oder ohne Digest).
us-central1.pkg.dev/my-image:foo* entspricht dem Namen und dem Tag-Präfix (z. B. myimage:foo und myimage:foobar) mit einem beliebigen Digest (oder keinem Digest).
us-central1.pkg.dev/my-project/my-image@sha256:77b0b75136b9bd0fd36fb50f4c92ae0dbdbbe164ab67885e736fa4374e0cbb8c entspricht dem Namen und Digest mit einem beliebigen Tag (oder keinem Tag).
us-central1.pkg.dev/my-project/my-image entspricht dem Namen, mit einem beliebigen Tag und/oder Digest.

Die Platzhalterzeichen * und ** können verwendet werden, um einen beliebigen Namen mit einem bestimmten Präfix abzugleichen. * stimmt mit Suffixen überein, die / nicht enthalten. ** stimmt mit Suffixen überein, die / enthalten können. ** kann jedoch nur nach einem / verwendet werden. * und ** können nicht mit Tags oder Digests verwendet werden.

Beispiel:

us-central1.pkg.dev/my-project/my-image* entspricht us-central1.pkg.dev/myproject/my-image, us-central1.pkg.dev/myproject/my-image1 und us-central1.pkg.dev/myproject/my-image2 mit einem beliebigen Tag und/oder Digest.
us-central1.pkg.dev/my-project/** entspricht us-central1.pkg.dev/myproject/my-image und us-central1.pkg.dev/my-project/some-directory/other-image mit einem beliebigen Tag und/oder Digest.

Namens- und Tag-Präfixe dürfen nicht leer sein. Daher ist * oder ** allein kein gültiges Muster und us-central1.pkg.dev/my-image:* auch nicht.

Ausnahme auf gkePolicy-Ebene

Das folgende Beispiel zeigt, wie Sie Images auf Plattformrichtlinienebene ausschließen. Alle Images in den Verzeichnissen exempt-images1 und exempt-images2 und ihren Unterverzeichnissen werden vom CV-Monitoring ausgeschlossen.

gkePolicy:
  imageAllowlist:
  - allow_pattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images1/**"
  - allow_pattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images2/**"
  checkSets:
      checks:
        ...

Die Richtlinie schließt unter imageAllowlist aufgeführte Images von allen Prüfsätzen (checkSets) aus, die unter gkePolicy aufgeführt sind.

Ausnahme auf checkSet-Ebene

Das folgende Beispiel zeigt, wie Sie Images auf der Ebene des Prüfsatzes ausnehmen:

gkePolicy:
  checkSets:
    imageAllowlist:
    - allow_pattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images1/**"
    - allow_pattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images2/**"
    checks:
      ...

In der Richtlinie werden Images unter imageAllowlist von allen Prüfungen ausgenommen, die unter checkSets aufgeführt sind.

Ausnahme auf Prüfungsebene

Das folgende Beispiel zeigt, wie Sie Images auf der Prüfebene ausnehmen:

gkePolicy:
  checkSets:
    checks:
      imageAllowlist:
      - allow_pattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images1/**"
      - allow_pattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images2/**"
      ...

Mehrere Prüfsätze verwenden

Eine CV-prüfbasierte Richtlinie kann mehr als einen Prüfsatz enthalten. CV wertet bei jeder Auswertung der Richtlinie einen Prüfsatz aus. Sie können sich Prüfsätze als Unterrichtlinien vorstellen, die in verschiedenen Situationen ausgewertet werden sollten. Wenn Sie beispielsweise unterschiedliche Prüfungen in Entwicklungsumgebungen anwenden möchten, als die in Produktionsumgebungen, können Sie die Prüfungen für jede Umgebung in einem separaten Prüfsatz platzieren: einen, der nur in der Entwicklungsumgebung und einen, der in der Produktionsumgebung ausgewertet wird.

Jeder Prüfsatz ist entweder auf einen Kubernetes-Namespace oder ein Kubernetes-Dienstkonto beschränkt. Der Bereich bestimmt, für welche Pods der Prüfsatz gilt.

Wenn ein Prüfsatz mit einem Bereich konfiguriert ist, gilt er nur für Pods, die in diesem Bereich ausgeführt werden.

Wenn ein Prüfsatz keinen Bereich hat, wird er als Standardprüfsatz bezeichnet. Dies bedeutet, dass die Prüfungen auf alle Pods angewendet werden, unabhängig vom Kubernetes-Namespace oder Dienstkontobereich.

Die meisten Beispielrichtlinien in den CV-Leitfäden verwenden nur einen Standardprüfsatz.

In der folgenden Beispielkonfiguration für die Richtlinie werden drei Prüfsätze konfiguriert:

gkePolicy:
  checkSets:
    - displayName: "Prod check set"
      scope:
        kubernetesNamespace: "prod-namespace"
      checks:
        - trustedDirectoryCheck:
            trustedDirPatterns: "gcr.io/my-project/prod-images"
        - imageFreshnessCheck:
            maxUploadAgeDays: 30
    - displayName: "Dev check set"
      scope:
        kubernetesNamespace: "dev-namespace"
      checks:
        - trustedDirectoryCheck:
            trustedDirPatterns: "gcr.io/my-project/dev-images"
    - displayName: "Default check set"
      checks:
        - alwaysDeny: true

In der Beispielkonfiguration ist der erste Prüfsatz auf prod-namespace beschränkt, sodass sich seine Prüfungen nur auf Pods auswirken, die in diesem Bereich ausgeführt werden. Der zweite Prüfsatz ist auf dev-namespace beschränkt, sodass sich seine Prüfungen nur auf Pods in diesem Bereich auswirken. Der dritte Prüfsatz ist ein Standardprüfsatz. Die Prüfungen gelten für alle Pods im Cluster, die außerhalb der Bereiche prod-namespace und dev-namespace ausgeführt werden.

Wenn CV den Prüfsatz Prod check set auswertet, wird Folgendes für die Images von Pods geprüft, die im Kubernetes-Namespace prod-namespace ausgeführt werden:

Die Images sind im vertrauenswürdigen Verzeichnis prod-images gespeichert.
Die Images wurden in den letzten 30 Tagen hochgeladen.

Wenn CV den Prüfsatz Dev check set auswertet, werden die im Kubernetes-Namespace dev-namespace ausgeführten Pods ausgewertet. Dabei wird geprüft, ob Images im Pod aus dem Verzeichnis dev-images stammen.

Der standardmäßige Prüfsatz dient als "Catchall". Mit der Always-deny-Prüfung wird sichergestellt, dass CV alle Pods protokolliert, die in einem anderen Namespace ausgeführt werden.

Wenn Sie ein Kubernetes-Dienstkonto als Bereich eines Prüfsatzes verwenden möchten, ersetzen Sie den Schlüssel kubernetesNamespace im Beispiel durch kubernetesServiceAccount. Der Wert hat das Format my-namespace:my-service-account.

Für Prüfsatz-Bereiche gelten die folgenden Regeln:

In einer Plattformrichtlinie kann nur ein Prüfsatz pro Bereich festgelegt werden.
Wenn eine Richtlinie sowohl Namespace-bezogene als auch Dienstkonto-bezogene Prüfsätze enthält, muss zuerst der Dienstkonto-bezogene Prüfsatz und dann der Namespace-bezogene Prüfsatz aufgeführt werden.
Es darf nur ein Standardprüfsatz vorhanden sein, der außerdem zuletzt aufgelistet sein muss.

Wenn eine Plattformrichtlinie Prüfsätze enthält, muss sie mindestens einen Standardprüfsatz enthalten. Eine Plattformrichtlinie ohne Prüfsätze ist zulässig, aber da keine Prüfungen vorliegen, die verletzt werden können, erstellt CV keine Logeinträge.

Legacy-CV

In diesem Abschnitt werden Legacy-CV-Richtlinien beschrieben. Wenn Sie mit CV noch nicht vertraut sind, empfehlen wir stattdessen die Verwendung von CV mit prüfbasierten Richtlinien.

Zur Unterstützung von Legacy-CV-Nutzern kann CV in Projekten aktiviert werden, die GKE ausführen. CV verwendet dann die Richtlinie zur Durchsetzung der Binärautorisierung, um alle Pods zu prüfen, die auf allen Clustern im Projekt ausgeführt werden, einschließlich Clustern, für die die Binärautorisierungserzwingung nicht aktiviert ist.

Weitere Informationen zum Verwenden von Legacy-CVs (verworfen) und Ansehen von Legacy-CV-Ereignissen in Cloud Logging.