Erhöhung der Container Security mit Kyverno

​​​​Kyverno UeberblickIn diesem Beitrag stelle ich ein Nachfolgeprodukt für die Pod Security Policies (PSP) vor. Wie Sie sicherlich bereits wissen, wird die PSP bald der Vergangenheit angehören (deprecated ab 1.21, entfernt in 1.25).  Kyverno ist eine von zwei auf dem Markt (Policy Agents) etablierten Lösungen, die als Alternativen für PSP in Frage kämen. Die zweite mögliche Lösung heißt „OPA with Gatekeeper“.

 

Was ist Kyverno und wofür wird es eingewendet?

 

Der ungewöhnlich klingende Name Kyverno wird aus dem Griechischen als verwalten bzw. regieren übersetzt. Ursprünglich wurde Kyverno von der Firma Nirmata entwickelt. Die Weiterentwicklung des Produktes wird als Open-Source-Projekt im Rahmen der CNCF fortgesetzt.

Kyverno ist eine Kubernetes-Policy-Engine, die eigens für Kubernetes entwickelt wurde und die auf den kubernetes-eigenen Ressourcen, Pattern und Schreibweisen basiert.  

Im Gegensatz zu „OPA with Gatekeeper“, welches eine eigene Programmiersprache (rego) zur Erstellung von Policies verwendet, erfordert Kyverno keine speziellen Kenntnisse. Die von Kyverno erstellten Policies sind Kubernetes-native Ressourcen.

Kyverno verwendet deklarative Kubernetes-YAML-Manifeste (Policies), die sich einfach erstellen und verwalten lassen. Es existieren bereits eine Reihe von fertigen Policies, die sofort einsatzbereit sind. Somit ermöglicht Kyverno, eine auf Best Practices-basierende Konfiguration zu erstellen.

 

Anwendungsfälle für Kyverno

 

Kyvernos Funktionsumfang geht weit über die Grenze der Pod-Sicherheit hinaus und sollte daher nicht ausschließlich als Nachfolger der Pod Security Policies betrachtet werden.

Hier sind einige Nutzungsszenarien aufgelistet. 

Die Pod Security gilt als einer der Kernbereiche der Kubernetes Security. Kyverno hat eine Reihe von vorkonfigurierten Sicherheits-Richtlinien, die sich gleich gut in den Bereichen Pod- und Workload-Security eingesetzt lassen.

Kyverno kann auch in den weiteren Bereichen der Kubernetes Security eingesetzt werden, wie z.B. Secrets, Namespaces, Network Policies usw. Kyverno kann die Best-Practice-Empfehlungen implementieren und dadurch die möglichen Vulnerabilities (CVEs) vorbeugen.

Kyverno kann die Zugriffsrechte wesentlich granularer als integrierte Funktionalität von Kubernetes verwalten.

Kyverno kann auch bei der Verwaltung von mandantenfähigen Kubernetes-Clustern behilflich sein, wie z.B. bei der Erstellung von Ingress überprüfen, dass alle neuen Ingress-Ressourcen eine eindeutige HTTP-Host-Pfad Kombination haben. 

Mit Hilfe der Mutationsregeln können die Pods mit nützlichen annotations (Labels) versehen werden. Die Möglichkeit jede Kubernetes Ressource mit einem oder mehreren Labels versehen zu können erleichtert die Suche und die Verwaltung der Ressourcen.  

Da Secrets oft in mehreren Namespaces vorhanden sein müssen und das manuelle Verteilen der Secrets sowohl zeitaufwändig als auch fehleranfällig ist, kann Kyverno genutzt werden, um Secrets von einem Quell-Namespace in eine beliebige Anzahl von Ziel-Namespaces zu kopieren.

Kyverno kann Sidecar Container erstellen, die von anderen Anwendungen (z.B. Hashicorp Vault) genutzt werden können.

 

Kyverno als Policy Agent

 

In seiner Rolle als Policy Agent kann Kyverno drei Kern-Szenarien abbilden:

Kyverno Ueberblick

  • Validieren von Ressourcen, bevor diese erstellt werden, und zwar in zwei Modi: audit und enforce

  • Verändern (Mutate) von Ressourcen auf Basis der vergebenen Richtlinien bzw. Best Practices.

  • Generieren (Generate) von zusätzlichen Ressourcen

1. Das Validieren ist die meistgenutzte Option aus den drei oberen Szenarien. In einer Validate-Policy werden die verbindlichen Eigenschaften definiert, mit denen eine bestimmte Ressource erstellt werden soll. Sobald die Erstellung einer neuen Ressource von einem Benutzer (oder Prozess) initiiert wird, werden die Eigenschaften dieser Ressource von Kyverno gemäß der existierenden Validierungsregel überprüft. Wenn die Validierungsprüfung nicht erfolgreich abgeschlossen wird, wird die Ressource je nach vorgegebenem Modus erstellt (audit) oder geblockt (enforce). Es gibt die Möglichkeit die Validierungsregel vollständig im Audit-Modus zu betreiben.

2. Mutate: Kyverno hat die Fähigkeit sowohl die neuen als auch die bereits vorhandenen (ab Version 1.7.0+) Ressourcen zu verändern. Die Veränderung kann während der Zulassungskontrolle oder bei der Erstellung und Aktualisierung von Objekten durchgeführt werden. In der Mutation-Richtlinien wird beschrieben, was und wie die Veränderung durchgeführt wird. Das typische Anwendungsszenario wäre, die Objekte mit Labels zu versehen.  Die Veränderung (Mutation) der Ressourcen findet immer vor der Validierung statt.

3. Die Generierung der Ressourcen ist selbsterklärend. Die Generate-Regeln können auf zwei Arten zum Einsatz kommen:

  • Wenn eine neue Kubernetes-Ressource (Create-Prozess in Kubernetes) erstellt wird, können die zusätzlichen Ressourcen (wie z.B. NetworkPolicy, ServiceAccount, PodDisruptionBudget, ResourceQuota, LimitRange usw.) erstellt werden.

  • Wenn die vorhandene Ressource von einem Ort zu einem anderen kopiert wird. Der Trigger für diese Option ist „synchronize: true“

Die häufigsten Verwendungsfälle für Generierungsregeln sind die Erstellung von: NetworkPolicy,  RoleBinding / ClusterRoleBinding und ConfigMaps.

 

Admission Controller

 

Der Admission Controller ist ein aktivierbares Plug-In von Kubernetes, welches dafür sorgt, dass alle Requests in einem Kubernetes-Cluster eine zweistufige Kontrolle passieren müssen, bevor diese als Objektdaten in die etcd-Datenbank eingetragen werden.

Die weitere Ausführung hilft, die allgemeine Funktionsweise des Admission Controllers zu verstehen.

Kubernetes AdmissionControl

1. Alle Anfragen (von Benutzern oder von eigenen Kubernetes-Bestandsteilen) im Kubernetes Cluster werden an den API-Server gesendet. Der API-Server beinhaltet eine Reihe von Komponenten, die ein Request (wie z.B. kubectl apply –f deployment.yaml ) passieren muss bevor dieser in die etcd geschrieben wird.

2. API http Handler – Es ist ein Webserver, der die http-Anfragen empfängt.

3. An dieser Stelle wird überprüft, wer der Benutzer ist und was er machen darf.

  • Authentifizierung: hier wird geprüft, ob Benutzer oder Dienstkonto auf den Kubernetes Cluster zugreifen dürfen.

  • Autorisierung: an dieser Stelle wird geprüft, ob der Benutzer die angegebenen Ressourcen im Cluster erstellen, löschen, aktualisieren oder auflisten darf.

4. Weiterhin kommt Mutating Admission ins Spiel. Mutating Admission ist standardmäßig nicht konfiguriert bzw. aktiviert. In diesem Schritt kann der Request an einer externen Komponente (repräsentiert durch Webhook) gesendet werden und anschließend der Modifikation unterzogen werden (z.B. mit zusätzlichen Tags versehen, die Felder können hinzuzufügt, geändert oder entfernt werden).

Die Mutation erfolgt immer vor der Validierung, so dass alle Validierungsregeln die Ergebnisse einer Mutation verifizieren können.

5/ 8. Ein WebHook ist (ein http-Callback) in unserem Fall eine Schnittstelle zu einer externen Komponente (wie z.B. Kyverno), die eine Anforderung entgegen nimmt und zurücksendet.

6. Die Object Schema Validation überprüft, ob die angepasste yaml-Datei weiterhin korrekt ist.

7. Validation Admission ist ebenfalls optional verfügbar, wird aber wesentlich öfter verwendet. Validation Admission kann die Objekte, die in einem Cluster erstellt werden sollen, an eine externe Anwendung zwecks Validierung weiterleiten. Diese externe Anwendung überprüft die yaml-Datei anhand der eigenen Richtlinien und trifft anschließend die Entscheidung, ob die getestete Datei ausgeführt werden darf. Wenn die Objekte aus der yaml-Datei nicht erstellt werden dürfen, wird der Benutzer mit einer Meldung darüber informiert.

9. Andernfalls werden die Inhalte in die etcd (Key-Value-Store) eingetragen.

 

Wie Kyverno funktioniert?

 

Wie Sie bereits erahnen können, ist die Kyverno-Funktionalität auf Basis des Admission Controllers aufgebaut.

Nach der Installation wird sich Kyverno als Mutation Webhook und Validating Webhook registrieren. Somit werden alle Mutation- und Validation-Requests über Kyverno durchlaufen.  Die Mutating-Policy wird immer zuerst angewendet, damit diese anschließend noch den Validierungsprozess unterzogen kann.

AdmissionControl Kyverno

Die drei folgende Module können als Kyverno Kernkomponenten bezeichnet werden:

Webhook – ist für den Empfang und die Verarbeitung der Zulassungsanfragen (AdmissionReview) verantwortlich.  Seine intergierte Monitoring-Komponente erstellt und verwaltet die erforderlichen Konfigurationen.

Generate Controller – ist für die Verarbeitung und den Lebenszyklus der erstellten Richtlinien verantwortlich.

Policy Controller – ist für die Erstellung / Aktualisierung / Löschung der Policy-Ressourcen sowie für die Status-Abfragen zuständig.

Kyverno unterstützt auch die hochverfügbare Bereitstellung (drei Instanzen) und wird als Deployment ausgeführt. Bei der Installation von Kyverno werden einige Kubernetes Artefakte innerhalb des Namespaces erstellt: Kyverno Pods, Kyverno Services, ConfigMap, ServiceAccount und Secret.

Kyverno-Namespace.png

Außerdem werden folgenden Cluster Ressourcen angelegt:

 

Kyverno Policies

 

Die Kyverno-Policy ist eine Sammlung von unterschiedlichen Regeln (Rules). Jede Regel beinhaltet eine match-Definition und selten eine exclude-Definition, um zu steuern, auf welchen Ressourcen die Richtlinien angewendet werden.

Kyverno Policy Rules

Die Liste der nutzbaren match-, und exclude-Definitionen:

Des Weiteren beinhalten jede Regel nur eine einzige untergeordnete validate-, mutate-, generate- oder verifyImages- Dekaration.

Jede Regel erhält im Groben folgende Komponenten: die Art von Ressourcen, für die die Richtlinie definiert ist, die Meldung, die dem User angezeigt wird, wenn eine Validierung/Ausführung fehlschlägt und das eigentliche Regelwerk.

Die Kyverno-Policies können sowohl für Ressourcen innerhalb des einzelnen Namespaces als auch auf der Cluster-Ebene angewendet werden.

Aktuell gibt es eine Reihe von fertigen Richtlinien, die viele Security Compliance und Best Practices abdecken. Die nicht konformen Manifeste werden sicher geblockt, falls jemand versucht, diese auf dem Cluster anzuwenden.

 

Fazit

 

Kyverno ist eine leicht zu implementierende und gleichzeitig sehr effiziente Lösung, die helfen kann:

Im Bereich Compliance gibt es bereits eine Reihe von IG BvC ​entwickelten Richtlinien, die mehrere BSI Grundschutzbausteine (SYS1.6 und APP4.4) abbilden.