SUSE Security Admission Controller vs OPA Gatekeeper

Sowohl OPA Gatekeeper als auch Kubernetes können Validierungs- und Mutationsrichtlinien schreiben.

Diese Richtlinien können auf jede Art von Kubernetes-Ressource abzielen, einschließlich benutzerdefinierter Ressourcen.

Sie schreiben OPA Gatekeeper-Richtlinien mit Rego. Rego ist eine Abfragesprache, die vom Open Policy Agent-Projekt erstellt wurde.

Sie können Admission Controller Richtlinien mit verschiedenen Paradigmen schreiben. Richtlinienautoren können sowohl traditionelle Programmiersprachen (wie Go, Rust und andere) als auch domänenspezifische Sprachen wie Rego und CEL verwenden. In Admission Controller schreiben Sie validierende und mutierende Richtlinien auf die gleiche Weise.

Manchmal benötigt eine Richtlinie Daten über den aktuellen Zustand des Clusters, um eine Validierungs- oder Mutationsentscheidung zu treffen. Zum Beispiel könnte eine Richtlinie, die Ingress-Ressourcen validiert, wissen müssen, welche anderen Ingress-Ressourcen bereits im Cluster definiert sind, um sicherzustellen, dass keine Konflikte auftreten. Admission Controller bezeichnet diese Richtlinien als "kontextbewusst".

Sowohl OPA Gatekeeper als auch Admission Controller unterstützen diese Arten von Richtlinien.

Bei der Bereitstellung von OPA Gatekeeper entscheidet ein Kubernetes-Administrator, welche Art von Clusterdaten den Richtlinien zur Verfügung gestellt werden soll, wenn sie ausgewertet werden.

Es ist wichtig zu betonen, wie diese Daten dann für alle bereitgestellten Richtlinien zugänglich sind.

Wenn eine OPA Gatekeeper-Richtlinie beispielsweise Zugriff auf Kubernetes-Secrets benötigt, können auch alle anderen bereitgestellten Richtlinien diese Daten lesen.

Umgekehrt bietet Admission Controller einen granularen Zugriff auf Clusterressourcen. Jede Richtlinie hat nur Zugriff auf die Ressourcen, die der Kubernetes-Administrator angibt. Der Versuch, unbefugte Daten zu lesen, wird sofort blockiert und den Clusteradministratoren gemeldet.

OPA Gatekeeper hat eine clusterweite benutzerdefinierte Ressource, die die Definition von Richtlinien sowie deren Durchsetzung und Standort ermöglicht.

Admission Controller hat zwei verschiedene Arten von benutzerdefinierten Ressourcen, die zur Deklaration von Richtlinien verwendet werden. Eine arbeitet auf Cluster-Ebene, die andere auf Namespace-Ebene. Der Name der benutzerdefinierten Ressource auf Namespace-Ebene ist AdmissionPolicy.

Richtlinien, die über eine AdmissionPolicy Ressource bereitgestellt werden, betreffen nur die Ressourcen, die innerhalb des Namensraums erstellt wurden, zu dem sie gehören. Deshalb können Sie nicht-administrativen Kubernetes-Nutzern die RBAC-Berechtigungen gewähren, die erforderlich sind, um AdmissionPolicy Ressourcen in den Namensräumen zu verwalten, auf die sie zugreifen können.

Dies ermöglicht es Kubernetes-Administratoren, die mit Richtlinien verbundenen Arbeiten zu delegieren.

OPA Gatekeeper und Admission Controller Richtlinien haben den Quellcode der Richtlinie (Rego für OPA Gatekeeper, CEL für Admission Controller) in der benutzerdefinierten Ressource, die eine Richtlinie in Kubernetes definiert.

Außerdem können Admission Controller Richtlinien den Quellcode der Richtlinie verwalten wie Container-Images (für Rego, Go, Rust, …​). Sobald sie erstellt sind, werden sie als OCI-Artefakte in Container-Registries gepusht.

Sie können Admission Controller Richtlinien mit Container-Image-Tools wie cosign aus dem Sigstore-Projekt signieren und verifizieren.

Sie können Admission Controller Richtlinien zwischen geografisch verteilten Container-Registries mit den traditionellen Werkzeugen und Prozessen verteilen, die für Container-Images übernommen wurden.

Sowohl OPA Gatekeeper als auch Admission Controller werden mit GitOps-Methoden verwaltet.

Für OPA Gatekeeper gibt es jedoch eine Kopplung zwischen dem Rego-Code der Richtlinie und der benutzerdefinierten Ressource, die verwendet wird, um sie in Kubernetes bereitzustellen. Dies führt zu zusätzlichen Schritten in CI/CD-Pipelines.

Rego hat Testwerkzeuge, die die Erstellung von Unit-Testsuiten ermöglichen. Tests zu schreiben und sie in einer CI/CD-Pipeline auszuführen, ist entscheidend, um sicherzustellen, dass Richtlinien wie erwartet funktionieren.

Um diese Testwerkzeuge zu verwenden, muss der Quellcode der Richtlinie in speziellen Textdateien verfügbar sein. Es ist unmöglich, den Quellcode aus den YAML-Dateien zu lesen, die verwendet werden, um die OPA Gatekeeper-Richtlinie zu deklarieren. Die CI/CD-Pipeline muss den Rego-Quellcode synchronisieren, um mit dem Code zu testen, der in der OPA Gatekeeper benutzerdefinierten Ressource definiert ist. Sie können dies mit Drittanbieter-Tools tun.

Admission Controller Richtlinien haben CI/CD-Pipelines wie traditionelle Microservices. In der Regel befindet sich der Quellcode in einem Git-Repository, und dann werden mit traditionellen CI/CD-Systemen Unit-Tests dagegen ausgeführt. Sie schreiben Unit-Tests mit den Testframeworks der Sprache, die zur Erstellung der Richtlinie verwendet wird. Sobald alle Tests bestanden sind, kompilieren Sie die Richtlinie zu WebAssembly und laden Sie sie in eine Container-Registry hoch. Diese Art von Pipeline wird normalerweise vom Autor der Richtlinie gewartet.

Kubernetes-Administratoren warten typischerweise andere Automatisierungspipelines, die auf neue Versionen der Richtlinie reagieren (unter Verwendung von Automatisierungstools wie Dependabot, Renovate bot, updatecli und anderen) oder auf Änderungen an der Richtlinienkonfiguration.

Die Pipeline testet die Richtlinie gegen verschiedene Arten von Anfragen. Sie können die Tests mit dem kwctl CLI-Tool durchführen, ohne dass ein laufender Kubernetes-Cluster erforderlich ist. Das kwctl CLI-Tool verwendet die gleiche Bewertungs-Engine, die auch vom Admission Controller Stack verwendet wird, der in einem Kubernetes-Cluster bereitgestellt wird.

Sowohl OPA Gatekeeper als auch Admission Controller können Richtlinien mit zwei verschiedenen Betriebsmodi bereitstellen:

Der gleiche Server bewertet alle OPA Gatekeeper-Richtlinien. Im Gegensatz dazu erlaubt Admission Controller die Definition mehrerer Bewertungsserver. Sie definieren diese Server durch eine benutzerdefinierte Ressource namens PolicyServer.

Bei der Deklaration einer Admission Controller Richtlinie entscheidet der Kubernetes-Administrator, welcher PolicyServer sie hostet.

Dies ermöglicht interessante Szenarien wie die folgenden:

Da Richtlinien hinzugefügt, entfernt und neu konfiguriert werden, könnten die bereits im Cluster vorhandenen Ressourcen nicht mehr konform sein.

Sowohl OPA Gatekeeper als auch Admission Controller verfügen über einen Scanner, der im Hintergrund arbeitet. Dieser Scanner bewertet bereits im Cluster definierte Ressourcen und kennzeichnet nicht konforme Ressourcen.

Der einzige Unterschied zwischen OPA Gatekeeper und Admission Controller besteht darin, wie die Scannergebnisse gespeichert werden.

OPA Gatekeeper fügt die Details zu Verstößen dem status-Feld einer gegebenen Constraint-benutzerdefinierten Ressource hinzu (siehe hier).

Admission Controller speichert stattdessen die Ergebnisse in einer Sammlung der von openreports.io definierten benutzerdefinierten Reports-Ressourcen.