K8s - Admission Controller Teil II

Gatekeeper, ein Admission Controller als Ersatz für Pod Security Policies

Wie im ersten Blog-Beitrag erwähnt, wird PSP in K8s v1.21 veraltet sein und in K8s v1.25 entfernt werden [1]. Gatekeeper als Admission Controller, der den Open Policy Agent enthält, ist eine großartige neue Wahl, um einige sicherheitsbezogene Probleme in Ihrem Cluster zu lösen. In diesem Blogbeitrag geben wir Ihnen einen Überblick über die Architektur und den Anwendungsfall in K8s.

Figure 1: The Functionality of the Open Policy Agent

Zunächst sprechen wir über den Open Policy Agent [2]. Er ist der Motor hinter allem, der eingehende Anfragen nach vorgegebenen Regeln und Daten auswertet. Wenn ein Dienst eine Nachricht erhält und eine Entscheidung über deren Verarbeitung benötigt, kann der Dienst den Open Policy Agent nutzen, um eine Entscheidung anzufordern, wie in Abbildung 1 dargestellt. Der Open Policy Agent nimmt eine Anfrage des Dienstes entgegen und gibt Entscheidungen auf der Grundlage von Daten und einer Reihe von Regeln zurück, die in einer logischen Programmiersprache namens Rego geschrieben wurden. In unserem Fall ist der API-Server von K8s der Dienst, und der Webhook initiiert einen Stellvertreter, der die Abfrage an den Open Policy Agent stellt, um festzustellen, ob der empfangene API-Aufruf gültig ist.

Das Erlernen einer neuen Programmiersprache ist jedoch keine gute Idee, wenn es sich nur um einen bestimmten Anwendungsfall in Ihrer Architektur handelt, da Sie zusätzliche Anlaufphasen für Ihre Mitarbeiter benötigen und Ihr Wissen verteilen müssen, damit alles auch dann funktioniert, wenn Ihre DevOps-Ingenieure nicht erreichbar sind. Darüber hinaus müssen Sie sich möglicherweise um die Daten kümmern, die der Open Policy Agent für die Entscheidung benötigt. Daher stellen wir Ihnen Gatekeeper als Implementierung des Open Policy Agent zur Verfügung, die die häufigsten Probleme für K8s und Zulassungscontroller, einschließlich PSPs, sofort löst.

Gatekeeper Architecture
Abbildung 2: Gatekeeper-Architektur, entnommen aus [3]

Abbildung 3 zeigt die High-Level-Architektur von Gatekeeper. Gatekeeper führt Pods und Webhooks im Cluster selbst aus, um Informationen über eingehende K8s-API-Anfragen an Gatekeeper-Controller weiterzuleiten. Gatekeeper umhüllt den Open Policy Agent und versorgt ihn mit allen notwendigen Informationen aus dem Status des Clusters, um Entscheidungen zu treffen.

Wie wir bereits wissen, benötigt der Open Policy Agent Regeln, um eingehende Anfragen zu bewerten. Gatekeeper stellt die Open Policy Agent-Regeln mithilfe von Vorlagen und Einschränkungen bereit. Wir werden uns das im letzten Teil dieses Blogbeitrags genauer ansehen. Für den Moment müssen wir nur wissen, dass dieser Ansatz die Generierung von Bibliotheken ermöglicht, was aus zwei Gründen gut ist: Erstens müssen die DevOps-Teams Rego nicht lernen, wenn sie bei vorhandenen Bibliotheken bleiben und den Open Policy Agent als Zulassungscontroller in ihren K8s-Clustern verwenden möchten. Es gibt beispielsweise eine Bibliothek für PSPs vom Gatekeeper-Projekt, die PSPs ohne umfassende Kenntnisse von Zulassungscontrollern oder Rego implementiert. Zweitens können sie dieselbe Bibliothek für mehr als einen Cluster verwenden, was Gatekeeper für Umgebungen mit mehreren Clustern gut macht.

Audit request in Gatekeeper
Abbildung 3: Beispiel einer Antwort auf eine Audit-Anfrage in Gatekeeper

Darüber hinaus bietet Gatekeeper umfangreiche und einfach zu verwendende Audit-Funktionen für vorhandene Regeln. Normale Zulassungscontroller prüfen durch API-Anfragen auf Verstöße, wenn eine Ressource hinzugefügt, geändert oder gelöscht wird, sodass Sie keine Einblicke in Ressourcen erhalten, die durch Richtlinienänderungen nicht mehr konform sind. Im Gegensatz dazu können Sie mit der Audit-Funktionalität von Gatekeeper den aktuellen Status Ihres Clusters überprüfen und vorhandene Verstöße melden. Schließlich kann Gatekeeper Ergebnisse in einer Konsole oder im Prometheus-Monitoring sichtbar machen.

Nachdem wir Ihnen die verschiedenen Anwendungsfälle und Funktionen von Gatekeeper im Detail gezeigt haben, konzentrieren wir uns im nächsten Teil des Blockposts auf die Implementierung der Regeln in Form von Vorlagen und Einschränkungen. Wir werden den einfach zu verwendenden, aber schwer zu beherrschenden Ansatz von Gatekeeper erläutern und eine mögliche Implementierung von Gatekeeper als validierender Zulassungscontroller in einem Multi-Cluster-Setup erstellen.

Falls Sie es verpasst haben, hier ist der erste Teil dieser Blog-Serie: Zulassungscontroller Teil 1

Weitere Blogbeiträge zu diesem Thema

Du hast Fragen? Schreib uns!
Hiermit akzeptiere ich die Datenschutzbestimmungen der Alice&Bob.Company GmbH.
Du hast Fragen? Schreib uns!
Sebastian Schäffer
Head of Business Operations & Growth
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.