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 Ihre Durchsetzungsrichtlinien für Projekt-Singletons für die Binärautorisierung aktualisieren, werden nur Images validiert, die nach der Aktualisierung bereitgestellt werden. Bereits laufende Pods 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 werden Sie von CV über die Ausführung von Pods informiert, die gegen Ihre aktualisierten Richtlinien verstoßen.

  • Bildmetadaten überwachen: CV bietet spezielle Prüfungen für Änderungen an Bildmetadaten, darunter:

    • Attestierungen: CV erstellt einen Logeintrag, wenn die Attestierungen für die Images der Pods nicht mehr gültig sind.
    • Aktualität: CV erstellt einen Logeintrag, wenn festgestellt wird, dass 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.

  • Probelaufüberwachung: Wenn Sie den Probelauf aktivieren, ermöglicht die Binärautorisierung die Bereitstellung aller Images. Wenn Sie CV mit einer Plattformrichtlinie aktivieren, die Ihrer Projekt-Singleton-Richtlinie entspricht, werden regelmäßig Images protokolliert, 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. Da jedoch eine übereinstimmende Plattformrichtlinie verwendet wird, protokolliert CV weiterhin regelmäßig Pods, die gegen Richtlinien verstoßen, einschließlich Pods, die mit Break-Glass bereitgestellt werden.

So funktioniert 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

Zur Überwachung laufender Pods werden mit CV mindestens alle 24 Stunden die mit jedem Pod verknüpften Images geprüft. CV überwacht auch Init-Container und sitzungsspezifische 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. CV erzeugt einen Logeintrag, wenn ein Image eines Pods gegen eine Prüfung verstößt. Der Logeintrag enthält nur die Pod-Images, die gegen die Plattformrichtlinie verstoßen. Wenn alle Images alle Prüfungen bestehen, werden keine Logeinträge erstellt.

Im CV werden weiterhin Richtlinienverstöße protokolliert, bis ein Pod mit nicht richtlinienkonformen Images beendet wird. Wenn nicht richtlinienkonforme Pods während des Intervalls zwischen den Validierungen beendet werden, können die endgültigen von CV generierten Logeinträge nach der Beendigung während der nächsten CV-Bewertung angezeigt werden.

Nicht richtlinienkonforme Pods sollten mindestens einmal protokolliert werden, auch bei kurzlebigen Pods.

CV beendet die ausgeführten Pods nicht.

CV verwendet eine Feedressource

Um Informationen zu Pods abzurufen, die in Ihrem GKE-Cluster ausgeführt werden, erstellt CV eine Feedressource namens binauthz-cv-cai-feed.

CV-Plattformrichtlinien

Wenn Sie CV verwenden möchten, müssen Sie zuerst Plattformrichtlinien konfigurieren.

Plattformrichtlinien unterscheiden sich von alten Binärautorisierungsrichtlinien, die auch als Projekt-Singleton-Richtlinien bezeichnet werden. Das Bereitstellungsprojekt kann zwar nur eine alte Singleton-Richtlinie für Projekte haben, Sie können aber 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-Durchsetzungsrichtlinie 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.

Mithilfe von Plattformrichtlinien können Bilder von der Bewertung durch CV ausgenommen werden.

Erforderliche Berechtigungen

Um Plattformrichtlinien aufzulisten oder zu beschreiben, 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

Wenn Sie eine Plattformrichtlinie aktualisieren, wird die vorhandene Richtlinie durch einen Richtlinienbeschreiber ü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 mehrere Plattformrichtlinien konfigurieren können, müssen Sie jede mit einem eindeutigen Ressourcennamen benennen. Wenn Sie einen gcloud CLI-Befehl ausführen, beziehen Sie sich mit der 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, z. B. eine lokale Plattformrichtlinie oder eine in einem anderen Projekt.

Mehrere Prüfungen pro Plattformrichtlinie

Sie können in jeder Plattformrichtlinie mehrere Prüfungen konfigurieren, indem Sie sie dem checks-Block der Richtlinie hinzufügen. Weitere Informationen zu bestimmten Prüfungen, die Sie konfigurieren können, finden Sie unter Prüfungen.

Wenn in Ihrer CV-Plattformrichtlinie mehr als eine Prüfung angegeben ist, werden Images, die durch eine Prüfung ausgewertet werden, auch durch die anderen Prüfungen ausgewertet.

Die Binärautorisierung prüft alle in der Plattformrichtlinie konfigurierten Prüfungen für jedes Image, es sei denn, das Image entspricht einem Muster in der Zulassungsliste für ausgenommene Images. Weitere Informationen finden Sie unter Ausgenommene Images.

Einzelprojekteinrichtung

Sie können CV in einem einzelnen Projekt einrichten.

Bei einer Einzelprojekteinrichtung richtet die Binärautorisierung automatisch die erforderlichen Rollen im Dienst-Agent für die Binärautorisierung ein.

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 Mehrfachprojektkonfiguration für zusätzliche Sicherheit finden Sie unter Aufgabentrennung.

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 in der Regel:

  1. Legen Sie fest, welche Prüfungen verwendet werden sollen.
  2. Erstellen Sie eine oder mehrere Plattformrichtlinien mit einer YAML-Datei für Richtlinien. In der Datei wird angegeben, welche Prüfungen Sie verwenden möchten.
  3. Erstellen Sie die Plattformrichtlinie. Die Richtlinie kann in einem Projekt Ihrer Wahl gespeichert werden.
  4. Wählen Sie aus, ob Sie CV für einzelne Cluster oder für eine Flotte aktivieren möchten.
  5. Prüfen Sie unter „Logging“ die CV-Protokolle auf Ereignisse.
  6. Prüfen Sie die Protokolle und aktualisieren Sie Ihren Build und andere Prozesse, um Images zu erstellen, die die Prüfungen bestehen.

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. In einigen Beispielen weiter unten in diesem Leitfaden wird sie 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 laufende Pods mit dieser Prüfung ü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 Always-Deny-Prüfung verwenden möchten, fügen Sie alwaysDeny: true in den checks-Block ein:

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

Der Wert von alwaysDeny kann nicht auf false festgelegt 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.

In der folgenden Beispiel-YAML-Datei für die Plattformrichtlinie werden von CV Pods mit Images protokolliert, die vor mehr als 30 Tagen in das Repository hochgeladen wurden, von dem aus sie 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 Notizen und Schlüsseln konfigurieren, die Sie in Ihrem Attestor 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 Attestierungsstellen für die Binärautorisierung werden bei der Attestierung von CVs Authentifizierungsstellen verwendet. 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 nach Bestätigungen in jedem Projekt, das im Feld containerAnalysisAttestationProjects aufgeführt ist.
  • Attestierungen werden weiterhin in Artefaktanalyse-Vorkommen gespeichert, können jedoch in mehr als einem Projekt gespeichert werden.
  • Sie müssen ein oder mehrere Projekte mit Attestationen explizit angeben, indem Sie den Ressourcennamen projects/ATTESTATION_PROJECT_ID verwenden.

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

Wenn Images mit einem Image-Tag anstelle eines Digests bereitgestellt werden, prüft CV sie zuerst anhand der ausgenommenen Images, 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

Bei der SLSA-Prüfung wird die SLSA-spezifische Herkunft der Images der Pods geprüft.

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 mithilfe dieser Plattformrichtlinie überprüft, werden folgende Punkte geprüft:

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

Bei der Sigstore-Signaturprüfung wird geprüft, ob Images mit Sigstore-Signaturen signiert wurden.

Diese Prüfung unterstützt nur in Artifact Registry gehostete Images. Es wird geprüft, ob eine aus Artifact Registry abgerufene Signatur mit einem Schlüssel in der Richtlinie erfolgreich überprüft 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 werden die vertrauenswürdigen Verzeichnisse in trustedDirPatterns aufgelistet. 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

Bei der Sicherheitslückenprüfung wird das Scannen auf Sicherheitslücken der Artefaktanalyse verwendet, um zu prüfen, ob die Images von Pods Sicherheitslücken enthalten. Dazu gehören auch neue Sicherheitslücken, die seit der Bereitstellung des Pods durch das Sicherheitsrisiko-Scannen erkannt wurden. Bei der Sicherheitslückenprüfung können Sie Schwellenwerte für die Schwere der Sicherheitslücke und bestimmte Sicherheitslücken (als CVEs) konfigurieren. Images mit Sicherheitslücken, die gegen die Sicherheitslückenprüfung verstoßen, werden im Logging protokolliert.

Wenn Sie diese Prüfung verwenden möchten, müssen Sie zuerst die Sicherheitsrisikoprüfung in der Artefaktanalyse aktivieren.

Die folgende Beispielkonfiguration für die 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 die Schweregrade des Common Vulnerability Scoring Systems (CVSS), die mit allen Sicherheitslücken verknüpft sind, die mit der Artefaktanalyse identifiziert werden können. Außerdem werden in blockedCves bestimmte CVEs (Common Vulnerabilities and Exposures) aufgeführt. 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

Um zu prüfen, 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.

Ausgenommene Images mit Zulassungslisten

Wenn Sie eine Plattformrichtlinie erstellen, können Sie Bilder von Prüfungen ausnehmen, indem Sie ihre URLs einer Zulassungsliste hinzufügen. Mit einer Zulassungsliste auf Richtlinienebene werden Images von der gesamten Richtlinie ausgenommen. 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 mit einer oder mehreren Bild-URLs übereinstimmen. Ein Zulassungslistenmuster kann eine der folgenden Formen haben:

  • Ein Präfix für Bildnamen, das mit dem Platzhalter * oder ** endet.
  • Nur ein Bildname, ohne Tag oder Digest.
  • Ein Image-Name mit einem Tag (oder einem 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 Zulassungslistenmuster:

  • us-central1.pkg.dev/my-project/my-image:latest@sha256:77b0b75136b9bd0fd36fb50f4c92ae0dbdbbe164ab67885e736fa4374e0cbb8c entspricht genau dem Image-Namen, -Tag und -Digest.
  • us-central1.pkg.dev/my-project/my-image:latest entspricht dem Namen und Tag mit einem beliebigen Digest (oder keinem 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.

Mit den Platzhalterzeichen * und ** können Sie jeden Namen mit einem bestimmten Präfix abgleichen. * 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 Zusammenfassungen 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:
  - allowPattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images1/**"
  - allowPattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images2/**"
  checkSets:
      checks:
        ...

In der Richtlinie werden Images unter imageAllowlist von allen Prüfungssätzen (checkSets) ausgenommen, die unter gkePolicy aufgeführt sind.

Ausnahme auf checkSet-Ebene

Das folgende Beispiel zeigt, wie Sie Bilder auf Ebene der Prüfgruppe ausschließen:

gkePolicy:
  checkSets:
    imageAllowlist:
    - allowPattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images1/**"
    - allowPattern: "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 Bilder auf Prüfebene ausschließen:

gkePolicy:
  checkSets:
    checks:
      imageAllowlist:
      - allowPattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images1/**"
      - allowPattern: "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.

In den meisten Beispielrichtlinien in den CV-Leitfäden wird nur ein Standardprüfsatz verwendet.

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 Umfang 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 die alten 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 Nutzern des bisherigen CV-Dienstes kann CV für Projekte aktiviert werden, in denen GKE ausgeführt wird. 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.

Nächste Schritte