K8s - Admission Controller Teil I
Warum brauchen Sie einen Admission Controller?
Admission Controllers Teil I - Warum brauchen Sie einen Admission Controller und wie Sie eine gute Lösung dafür finden.
Viele Unternehmen nutzen Kubernetes, um die Infrastruktur und den Zugriff auf ihre Dienste zu verwalten. Aufgrund des Betriebs und der umfassenden Funktionalität ist es unerlässlich, API-Aufrufe gegenüber den Kubernetes-Masterknoten zu regulieren und zu validieren.
Pod Security Policies (PSPs) sind eine gängige Methode, um Regelungen innerhalb Ihres Kubernetes-Clusters zu definieren, wie z. B. die Verweigerung der Nutzung von Root-Benutzern innerhalb der Pods oder die Zulassung nur bestimmter Volume-Typen im Cluster. PSPs sind jedoch mit K8s v1.21 veraltet und werden in K8s v1.25 [1] entfernt. Administratoren müssen also neue Methoden zur Durchsetzung ihrer Spielregeln planen. Die K8s-Dokumentation empfiehlt die Verwendung von Zutrittskontrollern als Ersatz für PSPs. In diesem Blog-Post stellen wir Admission Controller als Ersatz für PSPs vor und geben Ihnen praktische Informationen, um sie in Ihren Kubernetes-Cluster zu implementieren. Aufgrund seiner Komplexität unterteilen wir das Thema in drei Teile:
Im ersten Teil verschaffen wir uns einen kompakten Überblick über dieses Thema. Wie identifizieren Sie das Produkt, das Sie benötigen? Was müssen Sie beachten, bevor Sie den ersten Admission Controller einrichten? Der zweite Teil beschreibt die Architektur von Gatekeeper und dem Open Policy Agent als eine Lösung für einen Admission Controller. Er vermittelt Ihnen ein erstes Verständnis für die Vorteile und den produktiven Einsatz des Admission Controllers. Im letzten Teil stellen wir die verschiedenen Richtlinien und möglichen Anwendungsfälle vor.
Ein Admission Controller ist eine Funktion von K8s, die es Ihnen ermöglicht, K8s-API-Anfragen zu manipulieren oder zu verweigern, bevor die Zielressource erstellt, geändert oder gelöscht wird. Webhooks verbinden Anwendungen mit bestimmten Punkten der Ausführungspipeline im K8s API Server. Wir unterscheiden zwei Arten von Admission Controllern: Erstens ändern die Mutating Admission Controllers die Ressource, bevor sie bereitgestellt wird.
Zweitens prüfen die Validating Admission Controllers, ob die geänderte, gelöschte oder erstellte Ressource im Cluster die vom Benutzer vorgegebenen Richtlinien erfüllt. Abbildung 1 zeigt den gesamten Mechanismus. In Abbildung 1 werden zwei wichtige Punkte hervorgehoben: Erstens erfolgen alle Änderungen der Admission Controller nach der Authentifizierung und Autorisierung des Benutzers. Der Admission Controller ist also kein Werkzeug, um den Zugang zu Ihrem API-Server einzuschränken oder um festzulegen, was ein bestimmter Benutzer tun darf oder nicht. Zweitens erfolgt die Validierung nach der Mutation. Wenn Sie einen mutierenden Admission Controller verwenden, der eine bestimmte Ressource hinzufügt, z. B. ein Sidecar für Ihre Pods, können Sie diese separat validieren.
So können Admission Controller Ressourcen hinzufügen, die der Benutzer nicht in seinem Manifest definiert hat, oder sie können Einstellungen im Manifest des Benutzers erzwingen. Auf diese Weise bestimmen sie maßgeblich, wie der Cluster arbeitet, indem sie seine Komponenten nach vorgegebenen Regeln validieren. Infolgedessen können Sie den Admission Controller verwenden, um einige risikoreiche Sicherheitslücken innerhalb des Bereitstellungsmanifests zu schließen, z. B. die Verwendung des Root-Benutzers innerhalb eines Containers zuzulassen. Indem er unsichere Felddefinitionen oder fehlende Felder im Bereitstellungsmanifest identifiziert, verhindert der Admission Controller einige unsichere Einstellungen von Pods und Containern. PSPs lösten dieses Problem bis K8s v1.21. Dies macht die Verwendung eines Admission Controllers in K8s aus Sicherheitsgründen fast zwingend erforderlich.
Bevor Sie mit der Implementierung einer Lösung beginnen, nachdem Sie den Wert eines Admission Controllers erkannt haben, sollten Sie sich die Zeit nehmen, darüber nachzudenken, welche Erwartungen Sie haben und welche Einschränkungen Sie in Ihrem Cluster wirklich benötigen. Außerdem müssen Sie wissen, wie die Regeln innerhalb des Clusters verteilt werden sollen. D.h., wollen Sie Richtlinien nur in bestimmten Namensräumen definieren? Danach sollten Sie Ihre Admission Controllers entsprechend den bisherigen Erkenntnissen auswählen.
Derzeit gibt es zwei populäre Admission Controller, die wir hier kurz erwähnen wollen. Kyverno ist ein Admission Controller, der einfach zu bedienen ist, dem es aber an einer breiten Palette von feinkörnigen Implementierungstechniken für Regeln mangelt. Gatekeeper hingegen ist eine weiter verbreitete Lösung, die mehr Möglichkeiten zur Manipulation des Verhaltens bietet. Es bindet den Open Policy Agent ein, um gegen Regeln zu validieren, die der Benutzer sogar selbst schreiben kann. Infolgedessen ist Gatekeeper eher eine einfach zu bedienende, schwer zu beherrschende Lösung, die jedoch eine große Vielfalt für verschiedene Anwendungsfälle bietet. Nichtsdestotrotz befindet sich Gatekeepers Mutating Admission Controller-Funktionalität in der Beta-Phase, während Kyverno zum Zeitpunkt der Erstellung dieses Artikels eine funktionierende Implementierung hat. Letztendlich hängt die richtige Entscheidung für einen Admission Controller von Ihren Bedürfnissen ab.
Im nächsten Teil dieses Blog-Beitrags zeigen wir Gatekeeper als eine mögliche Lösung für einen validierenden Admission Controller, der die Funktionalität von Pod-Security Policies ersetzen und erweitern kann.
