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 Projekt-Singleton-Richtlinien für die Binärautorisierung aktualisieren, werden nur Images validiert, die nach der Aktualisierung bereitgestellt werden. Bereits ausgeführte 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 informiert Sie der CV über die Ausführung von Pods, die gegen Ihre aktualisierten Richtlinien verstoßen.
Bild-Metadaten überwachen: CV bietet spezifische Prüfungen für Änderungen an Bild-Metadaten, 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 erkannt wird, dass die Bilder 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 Singleton-Richtlinie für das Projekt 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. Wenn jedoch eine passende Plattformrichtlinie verwendet wird, protokolliert CV weiterhin regelmäßig gegen Richtlinien verstoßende Pods, einschließlich Pods, die mit Break-Glass bereitgestellt werden.
So funktioniert die 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
Um laufende Pods zu überwachen, prüft CV mindestens alle 24 Stunden die Bilder, die mit jedem Pod verknüpft sind. CV überwacht auch Init-Container und kurzlebige 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 Bilder 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 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 wenn sie nur kurzlebig sind.
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 mit dem Namen binauthz-cv-cai-feed.
CV-Plattformrichtlinien
Wenn Sie CV verwenden möchten, müssen Sie zuerst Plattformrichtlinien konfigurieren.
Plattformrichtlinien unterscheiden sich von Legacy-Richtlinien für die Binärautorisierung, auch Projekt-Singleton-Richtlinien genannt. Das Bereitstellungsprojekt kann nur eine alte Singleton-Richtlinie für Projekte haben, Sie können jedoch 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-Richtlinie 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.
Mit Plattformrichtlinien können Bilder von der CV-Bewertung ausgenommen werden.
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
Beim 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 den Cluster (eine lokale Plattformrichtlinie) oder in einem beliebigen anderen Projekt erstellen.
Da Sie eine Reihe von Plattformrichtlinien konfigurieren können, geben Sie jeder einen eindeutigen Ressourcennamen. Wenn Sie einen gcloud CLI-Befehl ausführen, verweisen Sie anhand 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, unabhängig davon, ob es sich um eine lokale Plattformrichtlinie oder eine in einem anderen Projekt handelt.
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 den einzelnen Prüfungen, die Sie konfigurieren können, finden Sie unter Prüfungen.
Wenn in Ihrer Plattformrichtlinie für die kontinuierliche Validierung mehr als eine Prüfung angegeben ist, werden Bilder, 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 in der Zulassungsliste für ausgenommene Images. Weitere Informationen finden Sie unter Ausgenommene Images.
Einzelprojekteinrichtung
Sie können die Funktion für vertrauliche Daten 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 Einrichtung mit mehreren Projekten 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:
- Entscheiden Sie, welche Prüfungen Sie verwenden möchten.
- 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.
- Erstellen Sie die Plattformrichtlinie. Die Richtlinie kann in einem Projekt Ihrer Wahl gespeichert werden.
- Wählen Sie aus, ob Sie CV für einzelne Cluster oder für eine Flotte aktivieren möchten.
- Prüfen Sie die CV-Logs in Logging auf Ereignisse.
- Prüfen Sie die Logs und aktualisieren Sie Ihren Build und andere Prozesse, um Bilder zu erstellen, die den Prüfungen entsprechen.
Schecks
In diesem Abschnitt werden die spezifischen Prüfungen beschrieben, die von CV bereitgestellt werden.
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 Pod 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 im Block checks hinzu:
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.
Im folgenden Beispiel für eine YAML-Datei für eine Plattformrichtlinie protokolliert CV Pods mit Bildern, die vor mehr als 30 Tagen in das Repository hochgeladen wurden, aus dem sie bereitgestellt wurden.
gkePolicy:
checkSets:
checks: