Ein Leitfaden zum Navigieren durch die Richtlinienüberlastung in den heutigen verteilten Systemen
Ich fordere euch auf, an der KubeCon teilzunehmen und eine Sitzung zum Thema "Politik" zu besuchen. Wenn Sie dort ankommen, sollten Sie sich nicht wundern, wenn Sie sich fragen: "Um welche Art von Politik geht es eigentlich?"
Auf der letzten KubeCon in Salt Lake City sprintete ich zwischen den Sessions, in denen das Thema "Politik" in den Titeln eine wichtige Rolle spielte. Aber für jeden Sprecher bedeutete das Wort etwas völlig anderes.

Da ich mich auf labelbasierte Netzwerkrichtlinien konzentriere, musste ich die Redner im Vorfeld oft fragen: „Geht es in dieser Richtliniensitzung um Netzwerkrichtlinien, Zulassungscontroller oder Compliance?“
Dieser Austausch offenbart ein wachsendes Problem in den heutigen Cloud-nativen und verteilten Computing-Ökosystemen. Der Begriff "Politik" wird so weit gefasst, dass er praktisch eine Abstraktion für sich ist.
Um dies zu entwirren, werfe ich einen genaueren Blick auf die acht verschiedenen Arten von Richtlinien, die häufig unter diesem weit gefassten Begriff diskutiert werden, und warum sie für das Verständnis der Infrastruktur, Sicherheit und Automatisierung in verteilten Systemen von entscheidender Bedeutung sind.
1. Netzwerk-Richtlinien
Netzwerkrichtlinien sind wichtig, um zu kontrollieren und zu verwalten, wie Systeme in einem Netzwerk miteinander kommunizieren, insbesondere in Umgebungen wie Kubernetes.
Die meisten Netzwerkrichtlinien verwenden einen Zulassungslistenansatz. Das bedeutet, dass Verbindungen standardmäßig blockiert werden, es sei denn, sie sind von der Richtlinie ausdrücklich zugelassen. Diese Richtlinien können Regeln verwenden, die auf IP-Adressen oder Bezeichnungen basieren, um zu entscheiden, welche Ressourcen kommunizieren können.
Da Microservices und containerbasierte Anwendungen immer häufiger vorkommen, ist es umso wichtiger, die Kommunikation von Diensten sorgfältig zu kontrollieren und sie bei Bedarf isoliert zu halten.
Beispielsweise sind die Netzwerkrichtlinien von Kubernetes in hohem Maße anpassbar. Sie können Verkehrsregeln für den internen Verkehr (Ost-West) und den externen Verkehr (Nord-Süd) festlegen. Diese Flexibilität macht sie zu leistungsstarken Werkzeugen für die Sicherheit von Systemen, allerdings ist ihre Erstellung und Verwaltung dadurch auch komplizierter.
2. Richtlinien für Zugangscontroller
Zugangscontroller sind spezialisierte Richtlinien in Kubernetes. Sie werten API-Anfragen aus, um zu entscheiden, ob sie zugelassen oder geändert werden sollen. Sie sind im Wesentlichen Torwächter. Sie setzen bestimmte Standards oder Sicherheitspraktiken im gesamten Cluster durch, bevor eine API-Anforderung weitergeleitet werden kann.
Richtlinien für Zugangscontroller können z. B. folgende Aktionen ausführen:
- Automatisches Durchsetzen von Ressourcenlimits
- Hinzufügen von Bezeichnungen zu Bereitstellungen
- Blockieren der Verwendung unsicherer Konfigurationen
Diese Art von Richtlinien kann Anforderungen abfangen und mutieren. Daher sind sie für die Aufrechterhaltung einer konsistenten Sicherheit innerhalb von Clustern von entscheidender Bedeutung. Sie befassen sich jedoch nur mit Richtlinien im Lebenszyklus von Kubernetes-API-Aufrufen.
3. OPA und Kyverno Richtlinien
Sind die Policen von OPA und Kyverno einfach nur Zulassungskontrolleure oder sind sie etwas mehr?
Open Policy Agent (OPA) und Kyverno bieten mehr als herkömmliche Zulassungscontroller. Während sie in Kubernetes häufig als Admission Controller fungieren, führen sie eine flexiblere, umfassendere Richtliniensprache ein. Dies ermöglicht es Unternehmen, komplexe Regeln über mehrere Systeme hinweg zu definieren und anzuwenden.
- OPA (Open Policy Agent) ist eine vielseitige Policy-Engine, die umgebungsübergreifend eingesetzt werden kann. Es verwendet eine Sprache namens Rego, die komplexe Richtlinienanforderungen bewältigen kann. Neben Kubernetes kann OPA auch Richtlinien für CI/CD-Pipelines, Microservices und sogar Cloud-Ressourcen verwalten.
- Kyverno ist eine Richtlinien-Engine, die speziell für Kubernetes entwickelt wurde. Es ist eine einfachere Möglichkeit, Richtlinien in YAML zu definieren. Viele Leute bevorzugen es für die Konfiguration von Kubernetes. Es funktioniert gut mit nativen Kubernetes-Objekten, was das Erstellen und Anwenden von Richtlinien erleichtert.
Diese Tools können steuern, was Zugriff auf ein System erhält, aber sie können noch viel mehr über eine Reihe von Anwendungen und Systemen hinweg tun. Sie können Folgendes verwalten:
- Lebenszyklus-Management
- Validierung
- Benutzerdefinierte Compliance-Prüfungen
4. Ressourcenkontingente und Grenzwertrichtlinien
Mit Ressourcenverwaltungsrichtlinien können Sie steuern, wie viel CPU, Arbeitsspeicher und Speicher ein Kubernetes-Cluster verwenden kann. Diese Richtlinien sind in freigegebenen Umgebungen wichtig, da sie verhindern, dass eine App oder ein Benutzer zu viele Ressourcen verwendet.
- Kontingente werden in der Regel für jeden Namespace festgelegt. Sie begrenzen die Gesamtmenge der Ressourcen, die ein Namespace verwenden kann, sodass kein einzelner Namespace zu viel übernimmt.
- Grenzwerte definieren die kleinste und größte Anzahl von Ressourcen, die ein Container oder Pod verwenden kann. Dadurch wird sichergestellt, dass keine einzelne Arbeitslast zu viele Ressourcen verbraucht und Probleme für den Rest des Systems verursacht.
Mit diesen Richtlinien können Administratoren Ressourcen ausgleichen, was besonders wichtig ist in Umgebungen mit vielen Benutzern oder Apps, die dynamisch skaliert werden. Diese Richtlinien tragen zwar dazu bei, das System stabil zu halten, machen aber auch die Dinge komplizierter, da sie mit anderen Richtlinienebenen wie Automatisierung und Zugangskontrollen interagieren.
Diese Richtlinien helfen Administratoren, Ressourcen auszugleichen, was besonders wichtig ist in Systemen mit vielen Benutzern oder Apps, die dynamisch skaliert werden. Die Verwaltung dieser Richtlinien kann jedoch eine Herausforderung darstellen. Sie überschneiden sich häufig mit anderen Richtlinien wie Automatisierung und Zugangskontrollen.
5. Pod-Sicherheitsrichtlinien (PSPs)
Pod-Sicherheitsrichtlinien (PSPs) in Kubernetes legen Sicherheitskonfigurationen auf Pod-Ebene fest. Dazu gehört, dass Container nicht mehr als root ausgeführt werden können oder dass bestimmte Linux-Funktionen erforderlich sind.
Aber PSPs werden in Kubernetes auslaufen. Sie werden durch neuere Optionen wie Pod Security Standards (PSS) und externe Tools wie OPA und Kyverno ersetzt.
PSPs wurden entwickelt, um granulare Sicherheitseinstellungen hinzuzufügen, die verhindern, dass Workloads mit übermäßig freizügigen Konfigurationen ausgeführt werden. Obwohl sie nützlich sind, kann die Verwaltung von PSPs zusammen mit anderen Policen verwirrend sein. Neuere Tools bieten flexiblere Möglichkeiten zur Durchsetzung von Sicherheit, oft unter dem allgemeinen Begriff "Sicherheitsrichtlinien".
6. Service-Mesh-Richtlinien
In Microservices-Umgebungen fügen Service-Meshes wie Istio oder Linkerd eine weitere Richtlinienschicht hinzu, die die Kommunikation zwischen Diensten sichert und überwacht. Diese Richtlinien führen häufig folgende Aktionen aus:
- Authentifizieren und autorisieren Sie den Datenverkehr: Service Meshes verwenden mTLS (Mutual TLS), um die Kommunikation zwischen Diensten zu verschlüsseln. Sie ermöglichen es Ihnen auch, Richtlinien festzulegen, für die Dienste miteinander kommunizieren können, und fügen so eine weitere Ebene der Zugriffskontrolle hinzu.
- Verwalten des Datenverkehrs: Service Mesh-Richtlinien steuern Routing, Lastausgleich und Failover. Dies erleichtert Dinge wie A/B-Tests, Canary-Releases oder das Weiterleiten von Datenverkehr an verschiedene Dienstversionen.
Im Gegensatz zu Netzwerkrichtlinien arbeiten Service Mesh-Richtlinien auf der Anwendungsebene und beeinflussen die Interaktion von Services. Diese Richtlinien sind für die Verwaltung des Service-to-Service-Datenverkehrs von entscheidender Bedeutung. Sie können jedoch manchmal verwirrend sein, da sie sich mit Netzwerkrichtlinien überschneiden.
7. Compliance-Richtlinien
Compliance-Richtlinien können Datenmanagement-, Zugriffs- und Betriebsstandards abdecken, um sicherzustellen, dass die Systeme gesetzliche oder interne Compliance-Anforderungen erfüllen, z. B. DSGVO, HIPAA oder SOC 2. Diese Richtlinien können in vielen Teilen eines Systems eine wichtige Rolle spielen und sich auf die Sicherheit, Protokollierung und Datenspeicherung auswirken.
Eine Konformitätsrichtlinie kann z. B. erfordern, dass Daten nur an bestimmten Speicherorten gespeichert werden (Datenresidenz) oder dass Überwachungsprotokolle für einen bestimmten Zeitraum aufbewahrt werden. In Kubernetes werden häufig Tools wie OPA und Kyverno verwendet, um diese Richtlinien durchzusetzen, indem Systeme kontinuierlich in Echtzeit überwacht und geprüft werden, um sicherzustellen, dass sie den Standards entsprechen.
Compliance-Richtlinien sind besonders wichtig in Branchen mit strengen Vorschriften, wie z. B. im Gesundheitswesen und im Finanzwesen. Da sie in vielen Teilen eines Systems funktionieren und sich oft mit Sicherheitsrichtlinien überschneiden, kann ihre Verwaltung komplex werden. Trotzdem sind sie von entscheidender Bedeutung, um sicherzustellen, dass die Systeme sicher, organisiert und konform bleiben.
8. Automatisierungs- und Lebenszyklusrichtlinien
Automatisierungsrichtlinien steuern, wann und wie Infrastrukturressourcen erstellt, aktualisiert oder entfernt werden. Diese Richtlinien sind ein wichtiger Bestandteil von Infrastructure-as-Code (IaC), bei dem Ressourcenkonfigurationen als Code geschrieben und über CI/CD-Pipelines verwaltet werden.
Automatisierungsrichtlinien können z. B. Aufgaben wie das automatische Skalieren von Ressourcen, das Bereinigen ungenutzter Ressourcen oder das Verwalten der Schritte im Lebenszyklus einer Bereitstellung übernehmen. Sie können auch in CI/CD-Pipelines integriert werden, um Builds auszulösen, Tests auszuführen und Bereitstellungen zu verwalten. Auf diese Weise werden selbstverwaltende Umgebungen geschaffen, die sich in Echtzeit an Änderungen der Arbeitslast anpassen können.
Automatisierungsrichtlinien können das Ressourcenmanagement vereinfachen und Best Practices in Cloud-nativen Umgebungen sicherstellen. Sie interagieren jedoch eng mit anderen Richtlinien, z. B. für die Ressourcenverwaltung und die Zugangskontrolle, was die Komplexität erhöhen kann.
Folgen Sie immer noch? Die Überschneidung von "Politik" geht weiter...
Wenn Sie noch nicht überwältigt sind, hier ist die Wendung. Viele Organisationen verfügen jetzt über Richtlinien für Richtlinien.
Diese werden als "Meta-Richtlinien" bezeichnet. Sie fungieren als Leitplanken und legen Regeln dafür fest, wer andere Richtlinien erstellen, verwalten oder anwenden kann.
Eine Metarichtlinie kann z. B. entscheiden, welche Teams bestimmte Netzwerkrichtlinien erstellen können oder wer berechtigt ist, Richtlinien für die Zugangssteuerung zu erstellen. Diese Richtlinien basieren häufig auf rollenbasierter Zugriffssteuerung (Role-Based Access Control, RBAC).
In großen Systemen sind RBAC-Richtlinien für Richtlinien unerlässlich. Sie stellen sicher, dass nur bestimmte Administratoren oder Teams Änderungen an Richtlinien vornehmen können. Durch die Durchsetzung strenger RBAC-Kontrollen stellen diese "Richtlinien für Richtlinien" sicher, dass andere Richtlinien nicht über die Grenzen hinausgehen oder in kritische Infrastrukturen eingreifen.
Abschließende Gedanken: Ein Fahrplan durch die Überlastung der Politik
Mit dem Wachstum von Cloud-nativen und verteilten Umgebungen wird sich die Idee der "Richtlinie" weiter verändern. Sie werden komplizierter, spezialisierter und manchmal sogar widersprüchlicher.
Um eine Überlastung von Richtlinien zu vermeiden, ist es wichtig, klare Namenskonventionen zu verwenden, eine Dokumentation zu erstellen, in der die einzelnen Richtlinientypen definiert sind, und Richtlinientools sinnvoll zu nutzen.
Und wenn Sie das nächste Mal auf einer Tech-Konferenz sind und "Politik" hören, nehmen Sie sich einen Moment Zeit und fragen Sie: "Welche?! " Es könnte Sie vor einer Menge Verwirrung bewahren – oder sogar vor einem Sprint quer durch die Halle!
Nehmen Sie noch heute Kontakt mit uns auf, um zu erfahren, wie Illumio Ihre Netzwerksicherheitsrichtlinien in Cloud-, Endpunkt- und Rechenzentrumsumgebungen vereinfachen kann.