Compliance-Richtlinien in Kubernetes integrieren

Für alle Unternehmen, die Kubernetes einführen wollen, steht neben grundsätzlichen Fragestellungen das Thema Sicherheit im Fokus. In diesem Zusammenhang geht es auch um den Punkt, wie interne Compliance- und Sicherheitsvorgaben in Kubernetes eingebunden werden können. Eine entsprechende Lösung, die bei der Sicherheit in der Containerorchestrierung helfen kann, sind Policies wie die Network Policies (Netzwerkrichtlinien) oder die Pod Security Policies (Pod-Sicherheitsrichtlinien, PSP). Zusätzlich gewinnt der Open Policy Agent (OPA) an Bedeutung. Der folgende Artikel beschreibt die Policies auf den verschiedenen Ebenen von Kubernetes.

Die Thematik verstärkt sich bei Unternehmen, die agile Frameworks wie SAFe im Einsatz haben. Dann sind die verantwortlichen IT-Teams gezwungen, die einzelnen Releases für die Infrastruktur und Applikationen mit höherer Schnelligkeit zu entwickeln und auszurollen. In Bezug auf Sicherheit und Testing müssen im Entwicklungsprozess und in der Infrastruktur verschiedene Aspekte des „Shift left“ berücksichtigt werden. Das heißt, einzelne Punkte dieser Bereiche werden im Lebenszyklus nach vorne gebracht. Um die damit verbundenen Risiken von vornherein gering zu halten, sollten grundlegende Sicherheitsrichtlinien frühzeitig im CI-/CD-Lifecycle von Kubernetes definiert und in den Prozess eingebunden werden. Andernfalls muss das Sicherheitsthema später im Rahmen der Release-Zyklen nachgeholt werden.

Verschiedene Drittanbieter wie Twistlock oder AquaSec bieten Sicherheitstools für Kubernetes an. Diese beinhalten hilfreiche Funktionen wie das Registry Scanning oder einen Laufzeitschutz. Andere Anwendungen wie HashiCorp Sentinel und Open Policy Agent (OPA) erleichtern die Umsetzung von „Policy as Code“ und ermöglichen die Implementierung enger Sicherheitskontrollen als Teil des Deployment-Prozesses.

Was ist Kubernetes?

Kubernetes – kurz K8s – ist ein System zur Containerorchestrierung. Die Open-Source-Lösung bietet die Möglichkeit, die Entwicklung, Skalierung sowie das Management von containerbasierten Applikationen deklarativ zu konfigurieren und zu automatisieren.

Kubernetes orchestriert sogenannte „Pods“ als kleinste Einheit. Unter Pods werden die Workload-Prozesse verstanden, die auf „Nodes“ (physische oder virtuelle Maschinen in einem Cluster) laufen. Sie beinhalten einen oder mehrere Container.

Der Cluster mit seinen Nodes wird über mehrere „Kubernetes Master“, gesteuert, die mit den einzelnen Nodes über auf diesen laufenden „Kubelets“ kommuniziert. Auf den Kubernetes Mastern läuft jeweils eine Instanz des etcd, der zentralen Schlüssel-Wert-Datenbank für sämtliche für das Management des Clusters wichtigen Informationen sowie der Controllermanager und ein „Scheduler“, der neu erzeugte Pods Nodes zuteilt. Die Controller überwachen und steuern den Cluster und seine Bestandteile. Außerdem läuft auf den Mastern der API-Server, das wichtigste Element in Kubernetes.

Open Policy Agent (OPA)

OPA ist ein Tool, das dabei unterstützt, dass Richtlinien eingehalten werden. Es geht darum für Unternehmen eine Möglichkeit zu schaffen, um Compliance-Richtlinien in Code abzubilden. Nicht Richtlinien-konforme API-Objekte können so erst gar nicht mehr deployt werden. Ein Verstoß gegen Compliance-Richtlinien wird von vornherein vermieden.

Das einfache Tool sorgt dafür, dass sich allgemeine Richtlinien in Kubernetes integrieren lassen. Open Policy Agent wird in der Regel als validating Webhook (Admission Controller) genutzt. Das heißt, soll eine neues API-Objekt erstellt werden, wird dieses vor der Erstellung durch den OPA überprüft, also validiert.

Entspricht das Objekt nicht den Policies, wird es abgelehnt und nicht erstellt oder ein bestehendes nicht verändert. Der Agent vergleicht die Objekte mit den Policies und sendet das Ergebnis zurück an den Client. Sprachlich sind die Richtlinien so gestaltet, dass sie den hohen Anforderungen von Unternehmen entsprechen. Die jeweiligen Regeln werden meist als Kubernetes-API-Objekte in den OPA geladen.

Des Weiteren implementiert OPA Regeln für die Zugangskontrolle, welche die Kubernetes-Ressourcen während der Erstell-, Aktualisierung- und Löschvorgänge validieren. Die Regelungen sorgen außerdem dafür, dass Richtlinien on-the-fly umgesetzt werden können. Das heißt, dass kein die Policy-Entscheidungen beeinflussender Services neu zusammengestellt werden muss.

Innovative Dienstprogramme wie Conftest (Conftest setzt mit Rego die gleiche Sprache wie der OPA ein) helfen dabei, Tests für strukturierte Konfigurationsdateien wie Kubernetes-Manifeste, Terraform-Code oder andere Konfigurationsdateien zu schreiben. Außerdem lassen sich im Rahmen des CI-Prozesses Code-Analysen anhand von OPA-Regeln umsetzen.

OPA versetzt IT- und Sicherheitsexperten in die Lage, sich auf die Analyse der Abfrageergebnisse zu konzentrieren und nicht auf deren Ausführung. Zur Unterstützung bietet der Hersteller eine Onlineplattform zum Testen an. Darüber hinaus stehen den Nutzern Plugins etwa für Visual Code zur Verfügung. Sie helfen, intuitive Richtlinien zu generieren. Damit wird die Entwicklung im Allgemeinen sowie das Prototyping enorm beschleunigt.

Ein Beispiel:

In einem Szenario wird das Deployment blockiert, wenn ein spezielles Label fehlt. Dass kann passieren, wenn etwa das Label „Environment“ in der Pod-Definition fehlt. Eine OPA-Richtlinie kann vorgeben, dass alle Pod-Definitionen zu evaluieren sind. Sollte der Parameter „metadata.label.environment“ bei den eingehenden Anfragen fehlen, wird das Deployment gestoppt.  Bezüglich der Bereitstellungszeit bei der Pod-Definition kennzeichnet OPA das Deployment mit einer nutzerdefinierten Nachricht, welche in der Richtlinie konfiguriert wird. Das heißt, im Ergebnis können Deployments nur erfolgreich umgesetzt werden, wenn dem Manifest das Label „Environment“ hinzugefügt wurde.

Die Einbindung von OPA in CI-/CD-Prozesse garantiert eine detaillierte Sicherheits- und Compliance-Kontrolle im Hinblick auf die Kubernetes-Bereitstellungen. Zu den fünf Standard-OPA-Richtlinien zählen:

1. Für alle Kubernetes-Dienste sollte ein gültiges SSL-Zertfikat vorhanden sein.
2. Auf den Einsatz von Containern mit Root-Rechten sollte verzichtet werden.
3. Es sollen nur signierte Container-Images laufen können.
4. Es sollten Images aus der privaten Container Registry verwendet werden.
5. CPU- und Speicheranfragen sollten begrenzt sein.

Network Policies (Netzwerk-Richtlinien)

Wir setzen bei Adacor Network Policies ein, wenn ein Unternehmen sie benötigt. Als Managed Cloud Solution Provider bieten wir ein Standard-Set (Standardregeln), das um individuelle Leistungen ergänzt werden kann.

Standardmäßig können alle Pods in einem Kubernetes-Cluster ohne Einschränkungen miteinander kommunizieren. Mithilfe der Network Policies können die in den Pods ausgeführten Dienste voneinander isoliert werden. Damit wird das Ziel verfolgt, den Blast-Radius (Radius zur Schadensbegrenzung) zu minimieren und die allgemeine Sicherheit zu verbessern. Mittlerweile unterstützt Kubernetes eine Vielzahl von Layer 2- und Layer 3-Netzwerk-Plugins von ISVs (Independent Software Vendor) und Cloud-Service-Providern. Jedes Modul hat Vor- und Nachteile. Services Meshes wie Istio oder Envoy bieten teilweise einen Layer-7-Schutz wie die Nutzer-Authentifizierung, TLS (Transport Layer Security) etc.

Die folgende Network Policy erlaubt beispielhaft eingehende DB-Verbindungen von Pods, die speziellen Bezeichnungen (Freitext/Labels) wie „Applikation: Web“ entsprechen:

Netzwerkrichtlinien können im Hinblick auf den Datenverkehr zu folgenden Zwecken standardisiert werden:

• Verhinderung der Kommunikation zwischen den Pods
• Erlaubnis der Kommunikation zwischen speziellen Pods
• Zulassung des Datenverkehrs von bestimmten Namespaces

Pod Security Policies (Pod-Sicherheitsrichtlinien, PSP)

Bei Adacor sind in Kubernetes immer Pod Security Policies aktiv.

Während OPA-Richtlinien Kubernetes-Deployments validieren und Network Policies die Isolation des Datenverkehrs zwischen den Diensten gewährleisten, ermöglichen PSPs die Einschränkung von Zugriffen etwa auf diverse systemnahe Ressourcen. So wird eine Vielzahl von Sicherheitskontrollen auf Betriebssystemebene unterstützt wie zum Beispiel SELinux, AppArmor oder SecComp.

Die folgende Policy sorgt dafür, dass Container nur als Non-Root-User ausgeführt werden dürfen, um eine nicht legitimierte Rechteausweitung zu verhindern:

Mit einer PSP ist es beispielsweise möglich, …

1. Zugriffe auf Volumetypen zu beschränken,
2. … Aktionen im Kernel-Bereich zu erlauben,
3. … AppArmor- oder SecComp-Profile zu forcieren,
4. … die Nutzung von Hostports zu erlauben,
5. … den SELinux-Kontext der Container zu setzen.

Fazit: Policies bieten ein solide Basis

Kubernetes bietet Grundelemente wie Pod Security Policies, Network Policies und Quotas, um die Berechtigungen und Ressourcennutzung von Containern einzuschränken. Komplexere Richtlinien sind hiermit nur sehr eingeschränkt oder gar nicht umsetzbar. Tools wie der Open Policy Agent wurden entwickelt, um diese Herausforderungen zu meistern. Um einige Security-Richtlinien umzusetzen, eignen sich Grundelemente wie die Network Policies, die Pod Security Policies gut. Um jedoch feingranulare und flexiblere Regeln umzusetzen, ist der OPA wesentlich besser geeignet.

Weitere spannende Informationen zu Kubernetes finden Sie hier: