|
Dieses Dokument wurde mithilfe automatisierter maschineller Übersetzungstechnologie übersetzt. Wir bemühen uns um korrekte Übersetzungen, übernehmen jedoch keine Gewähr für die Vollständigkeit, Richtigkeit oder Zuverlässigkeit der übersetzten Inhalte. Im Falle von Abweichungen ist die englische Originalversion maßgebend und stellt den verbindlichen Text dar. |
|
Dies ist eine unveröffentlichte Dokumentation für Admission Controller 1.34-dev. |
Rego
|
Rego-Unterstützung ist in diesen Versionen verfügbar:
Rego-Richtlinien unterstützen kontextabhängige Daten ab Version SUSE Security Admission Controller 1.9. |
Die Rego-Sprache ist eine domänenspezifische Sprache, die es ermöglicht, Richtlinien als Code zu implementieren. Rego ist eine von Datalog inspirierte Sprache.
Es gibt zwei Möglichkeiten, Rego-Richtlinien zu schreiben, um Richtlinien als Code in Kubernetes, Open Policy Agent und Gatekeeper zu implementieren.
Die nächsten Abschnitte zeigen, wie sich die beiden Frameworks unterscheiden, obwohl sie dieselbe Sprache verwenden. Wenn Sie mehr an der Admission Controller Implementierung interessiert sind, können Sie direkt die spezifische Dokumentation des Frameworks besuchen, die unten verlinkt ist.
Eine Sprache, zwei Frameworks
Open Policy Agent (OPA)
Open Policy Agent ist ein Projekt, das es Ihnen ermöglicht, Richtlinien als Code in jedem Projekt zu implementieren. Sie können OPA für jede richtlinienbasierte Überprüfung verwenden, die Ihre Anwendung benötigt.
In diesem Kontext bedeutet das Schreiben von Richtlinien für Kubernetes einfach, OPA zu nutzen. Durch die Verwendung von Kubernetes Admission Webhooks ist es möglich, Anfragen mit OPA zu bewerten, das die in Rego geschriebenen Richtlinien ausführt.
OPA hat eine optionale Integration mit Kubernetes über sein kube-mgmt Sidecar.
Wenn es auf Kubernetes bereitgestellt wird und der OPA-Server die Rego-Richtlinien bewertet,
kann es die konfigurierten Kubernetes-Ressourcen in Rego replizieren.
So sind diese Kubernetes-Ressourcen für alle Richtlinien sichtbar.
Mit OPA können Sie Richtlinien innerhalb der ConfigMap-Objekte von Kubernetes definieren.
Sie können mehr darüber auf
der Projektseite lesen.
Betrachtung der Unterschiede
Sowohl OPA als auch Gatekeeper-Richtlinien verwenden Rego, um Richtlinien als Code zu beschreiben. Jede Lösung hat Unterschiede beim Schreiben von Richtlinien in Rego, wie in den nächsten Abschnitten gezeigt wird.
Einstiegspunkt
Der Einstiegspunkt ist der Name einer Regel innerhalb eines Pakets und ist die Regel, die zur Laufzeit aufgerufen wird, wenn die Richtlinie ausgeführt wird.
Aktuelle Einschränkungen
Kontextabhängige Richtlinien
Kontextabhängige Richtlinien sind Richtlinien, die die Eingabeanfrage nicht isoliert bewerten.
Sie berücksichtigen andere Faktoren, um eine Entscheidung zu treffen.
Zum Beispiel eine Richtlinie, die namespaced Ressourcen bewertet und eine Annotation im übergeordneten Namespace verwendet, um etwas in der Richtlinie zu konfigurieren.
Ein weiteres Beispiel wäre eine Richtlinie, die Ingress Ressourcen bewertet, aber zur Entscheidungsfindung auch die Liste der vorhandenen Ingress Ressourcen hat.
Die Idee der kontextabhängigen Richtlinien kann auch auf benutzerdefinierte Ressourcen ausgeweitet werden, sodass Ihre Richtlinie möglicherweise eine Anfrage basierend auf den aktuell verwendeten benutzerdefinierten Ressourcen bewerten möchte.
Sowohl OPA als auch Gatekeeper unterstützen kontextabhängige Richtlinien, beginnend mit Version Admission Controller 1.9.
Weitere Details zu kontextabhängigen Richtlinien finden Sie hier.
Mutierende Richtlinien
Gatekeeper unterstützt mutierende Richtlinien, aber Admission Controller hat mutierende Richtlinien mit Gatekeeper-Kompatibilität noch nicht implementiert. Sie können Richtlinien verwenden, die das Admission Controller SDK nutzen, um mutierende Richtlinien zu schreiben, aber derzeit können Sie mutierende Gatekeeper-Richtlinien in Admission Controller nicht ausführen.