Warum Sie einen Kubernetes-Admission-Controller benötigen

Wenn Sie noch keine Erfahrung als Kubernetes-Operator oder -Administrator haben, sind Admission-Controller möglicherweise neu für Sie. Diese Controller arbeiten größtenteils im Hintergrund und sind vielfach als integrierte Plugins verfügbar. Sie können jedoch erheblich zur Sicherheit eines Deployments beitragen.

Admission-Controller fangen API-Anfragen ab, bevor sie den API-Server erreichen, und können sie ablehnen oder ändern. Das gilt für die meisten Arten von Kubernetes-Anfragen, mit Ausnahme reiner Leseanfragen, die nicht von den Controllern verarbeitet werden. Admission-Controller bearbeiten Anfragen, nachdem sie ordnungsgemäß authentifiziert und autorisiert wurden.

In diesem Beitrag geht es um die Gründe für den Einsatz von Kubernetes-Admission-Controllern. Außerdem wird erläutert, welche Vorteile eine umfassendere Kenntnis ihrer Funktionen bietet.

Mehrere Admission-Controller sind standardmäßig aktiviert, da die meisten üblichen Kubernetes-Vorgänge auf sie angewiesen sind. Die meisten dieser Controller sind Teil des Kubernetes-Quellcodes und als Plugins kompiliert. Es ist jedoch auch möglich, Admission-Controller von Drittanbietern zu programmieren und bereitzustellen. Einige Beispiele dazu folgen weiter unten. Eine ausführlichere Beschreibung der Implementierung von Admission-Controllern finden Sie in der Kubernetes-Dokumentation.

Standardmäßige Admission-Controller

Kubernetes bietet mehrere integrierte Admission-Controller. Ein einfaches Beispiel ist DefaultIngressClass, das Ingress-Objekten, für die noch keine Klasse festgelegt wurde, die Standard-Ingress-Klasse zuweist. Ähnlich weist DefaultStorageClass PersistentVolumeClaims ohne festgelegte Klasse die Standard-Storage-Klasse zu. Dieser Controller muss aktiviert sein, damit eine dynamische Speicherbereitstellung auf Basis der Storage-Klasse möglich ist.

Admission-Controller können wesentlich zur Sicherheit beitragen. So können sie beispielsweise Denial-of-Service-Angriffe (DoS) auf mandantenfähigen Clustern abmildern. Betrachten Sie das Plugin LimitRanger, das – wie der Name schon sagt – Ressourcenlimits durchsetzt. Diese legen für jeden Namespace verbindliche Bereiche für den Ressourcenverbrauch fest. So wird verhindert, dass Mandanten sich gegenseitig Ressourcen entziehen.

Ein weiteres Problem ist das sogenannte Event-Flooding: Dabei wird der Cluster mit Ereignissen überflutet und kann andere legitime Anfragen nicht mehr angemessen verarbeiten. Der Controller EventRateLimit ist ein wirksames Mittel, um solche Szenarien abzumildern. Er kann die Ereignisrate pro Namespace oder pro Nutzer begrenzen.

Darüber hinaus gibt es zwei wichtige Controller, mit denen Entwickler ihre Admission-Plugins als Webhooks ausführen können, die zur Laufzeit konfiguriert werden. MutatingAdmissionWebhook ermöglicht Webhooks, übermittelte Ressourcen zu ändern, und wird typischerweise zur Durchsetzung benutzerdefinierter Standardwerte verwendet. Der Controller ValidatingAdmissionWebhook ermöglicht registrierten Webhooks hingegen, zu entscheiden, ob eine API-validierte Ressource in ihrem endgültigen Zustand die Verarbeitungskette durchläuft oder vollständig verworfen wird.

Zweck der Controller

Ursprünglich führte man mehrere Dienste auf einem physischen Rechner aus, indem man virtuelle Maschinen auf demselben Host betrieb und ihre Betriebssysteme durch einen Hypervisor voneinander trennte. Ein komplexes System aus Cloud-Konfigurationen – etwa den von AWS definierten – hielt die Systeme getrennt und stellte sicher, dass Mandanten einander nicht versehentlich oder absichtlich schaden konnten.

Kubernetes wurde zunächst als kooperatives System konzipiert, das von einer einzelnen Organisation oder einem einzelnen Nutzer verwendet werden konnte. Zudem setzte es viel stärker als andere Cloud-Systeme auf gegenseitige Rücksichtnahme. Doch mit der wachsenden Vielfalt verfügbarer Deployments und der zunehmenden Fähigkeit von Kubernetes, größere Cluster zu verwalten, wird es immer wichtiger, Richtlinien durchzusetzen, die verhindern, dass ein einzelner Nutzer den Betrieb eines Systems beeinträchtigt.

Um diesen Prozess zu automatisieren, benötigen Organisationen ein Richtliniensystem. Kubernetes bietet zwar einige integrierte Funktionen, verfügt aber nicht über die Möglichkeiten einer voll ausgestatteten, spezialisierten Richtlinien-Engine.

Externe Richtlinien-Engines

Die beiden führenden Open-Source-Richtlinien-Engines für Kubernetes sind Open Policy Agent (OPA) Gatekeeper und Kyverno.

Beide Engines wurden der Cloud Native Computing Foundation (CNCF) gespendet, die sich der Standardisierung und Verbreitung cloudnativer Technologien widmet. Sie ist der Linux Foundation unterstellt. Kubernetes ist ebenfalls ein CNCF-Projekt.

Der wichtigste Vorteil von Kyverno: Sie müssen keine zusätzliche Sprache erlernen. Alle Richtlinien werden als Kubernetes-Ressourcen definiert. Gatekeeper nutzt dagegen die deklarative Sprache Rego von OPA. Gatekeeper ist Teil des umfassenderen OPA-Systems, während Kyverno ein eigenständiges Kubernetes-Projekt ist. Zusammengefasst ist Gatekeeper das ausgereiftere Projekt, Kyverno hingegen leichter zu erlernen.

Ihr benutzerdefinierter Admission-Controller

Mit Webhooks können Sie die Logik eines benutzerdefinierten Admission-Controllers in jeder Sprache programmieren, die HTTP-Anfragen verarbeiten und JavaScript Object Notation (JSON) zurückgeben kann. Go, Python oder Ruby sind beispielsweise geeignete Optionen.

Das folgende Beispiel zeigt, wie Sie einen Webhook für einen benutzerdefinierten Admission-Controller einrichten. Er ähnelt dem oben vorgestellten LimitRanger und weist Anfragen für Pods zurück, die die Ressourcenlimits des Namespace überschreiten. Beachten Sie, dass dieses Beispiel nicht den vollständigen Quellcode des Controllers enthält. Einen genaueren Einblick in den Prozess erhalten Sie in der Kubernetes-Dokumentation zu Admission-Webhook-Servern.

Registrieren Sie zunächst den Webhook mit einem Konfigurationsobjekt:

1apiVersion: admissionregistration.k8s.io/v1beta1
2kind: ValidatingWebhookConfiguration
3metadata:
4  name: mywebhook
5webhooks:
6  - name: mywebhook
7    clientConfig:
8      service:
9        name: mywebhook
10        namespace: project1
11        path: "/hook"
12    rules:
13      - operations: ["CREATE"]
14        apiVersions: ["v1"]
15        apiGroups: [""]
16        resources: ["pods"]

Damit wird der ValidatingWebhookController über den Webhook informiert. Außerdem werden der aufzurufende Dienst und der Pfad angegeben, den der Controller im Container mit dem Server überprüfen soll. Darüber hinaus werden die Regeln festgelegt, anhand derer entschieden wird, ob der Webhook aufgerufen wird. Dieses Beispiel konzentriert sich auf die Erstellung neuer Pods.

In der Praxis würde diese Ressource zuletzt im Cluster erstellt – nachdem ein Deployment für den Webhook-Server eingerichtet wurde. Das Deployment umfasst einen Dienst, der der Definition in der obigen Datei entspricht:

1apiVersion: v1
2kind: Service
3metadata:
4  name: mywebhook
5  namespace: project1
6spec:
7  - ports:
8      name: mywebhook
9      port: 80
10      targetPort: 8000

Unten sehen Sie ein Beispiel für ein Webhook-Deployment, das sich nicht von einer gewöhnlichen App unterscheidet. Wir gehen nicht darauf ein, wie sich die Kommunikation mit Transport Layer Security (TLS) absichern lässt, obwohl dies dringend empfohlen wird.

1apiVersion: apps/v1
2kind: Deployment
3metadata:
4  name: mywebhook
5  namespace: project1
6spec:
7  selector:
8    matchLabels:
9      app: mywebhook
10  template:
11    metadata:
12      labels:
13        app: mywebhook
14    spec:
15      containers:
16        - image: webhook1:latest
17          name: mywebhook

Nachdem eine Anfrage zum Erstellen eines neuen Pods an Kubernetes übermittelt und vom ValidatingWebhook weitergeleitet wurde, werden die relevanten Informationen als POST-Anfrage an den konfigurierten URL-Pfad gesendet. Sie enthält ein JSON-Objekt, das der Webhook verarbeitet. Um die Anfrage zu bestätigen, geben Sie eine Antwort ähnlich der folgenden zusammen mit dem Statuscode 200 OK zurück:

1{
2  "apiVersion": "admission.k8s.io/v1",
3  "kind": "AdmissionReview",
4  "response": {
5    "uid": "6ce7a33c-ea67-40e5-9cc8-f710d31985dc",
6    "allowed": true
7  }
8}

Das Feld uid wird aus der Anfrage übernommen, um Anfragen den Antworten zuzuordnen. Damit der Pod nicht erstellt wird, muss das Feld allowed auf false gesetzt und ein HTTP-Fehlercode zurückgegeben werden.

Ein benutzerdefinierter Admission-Controller kann so einfach wie in diesem Beispiel oder wesentlich komplexer sein. Eine ausführlichere Übersicht finden Sie in der Dokumentation zu Admission-Webhooks.

Fazit

Ein Kubernetes-Admission-Controller kann Anfragen an den API-Server ändern oder ablehnen, bevor das Objekt gespeichert wird. Kubernetes bietet zahlreiche vielseitige integrierte Controller, darunter mehrere vorab kompilierte Plugins und zwei Arten von Admission-Control-Webhooks. Durch die Programmierung eigener Webhooks und Controller lassen sich jedoch mehr Flexibilität und eine präzisere Steuerung erreichen.

Admission-Controller und Webhooks ermöglichen es Projekten, Richtlinien-Engines wie OPA Gatekeeper und Kyverno bereitzustellen. Außerdem lässt sich ein benutzerdefiniertes Admission-System einfach über HTTP-fähige Webhooks in jeder Sprache implementieren, die HTTP-Antworten mit einer JSON-Nutzlast zurückgeben kann.

Insgesamt sind Admission-Controller nur ein Bestandteil einer umfassenden Kubernetes-Sicherheitsstrategie. In jeder Phase des Softwareentwicklungslebenszyklus bestehen Risiken und Sicherheitslücken. Doch ihre Eindämmung muss nicht den gesamten Workflow stören. Eine auf Sicherheit spezialisierte Organisation kann wertvolle Einblicke bieten, wenn Sie nach der passenden Expertise suchen.

Chris Laux entwickelt seit mehr als 20 Jahren Software in verschiedenen Programmiersprachen.