Ein Leitfaden zur Bewältigung der Richtlinienflut in den heutigen verteilten Systemen

Ich fordere Sie auf, an der KubeCon teilzunehmen und an einer Sitzung zum Thema „Politik“ teilzunehmen. Wenn Sie dort ankommen, wundern Sie sich nicht, wenn Sie sich fragen: „Um welche Art von Richtlinie geht es eigentlich?“

Auf der jüngsten KubeCon in Salt Lake City musste ich zwischen den Sessions hin und her springen, bei denen „Politik“ im Vordergrund stand. Aber für jeden Redner bedeutete das Wort etwas völlig anderes.

Da sich jemand mit Netzwerkrichtlinien auf der Grundlage von Labels beschäftigte, musste ich die Redner oft vorher fragen: „Geht es in dieser Policy-Sitzung um Netzwerkrichtlinien, Zugangskontrolleure oder Compliance?“

Diese Börsen offenbaren ein wachsendes Problem in den heutigen Cloud-nativen und verteilten Computerökosystemen. Der Begriff „Politik“ wird so breit verwendet, dass er praktisch eine Abstraktion für sich ist.

Um dies zu entwirren, werde ich einen genaueren Blick auf die acht verschiedenen Arten von Richtlinien werfen, die unter diesem weit gefassten Begriff häufig erörtert werden, und darauf, 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 Sie einen Allow-List-Ansatz. Das bedeutet, dass Verbindungen standardmäßig blockiert werden, sofern sie nicht ausdrücklich durch die Richtlinie zugelassen werden. Diese Richtlinien können Regeln verwenden, die auf IP-Adressen oder Labels basieren, um zu entscheiden, welche Ressourcen kommunizieren können.

Als Microservices und containerbasierte Anwendungen Da es immer üblicher wird, ist es noch wichtiger, die Kommunikation der Dienste sorgfältig zu kontrollieren und sie bei Bedarf isoliert zu halten.

Kubernetes-Netzwerkrichtlinien sind beispielsweise hochgradig 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 Tools für die Sicherheit von Systemen, macht aber auch deren Aufbau und Verwaltung komplizierter.

2. Richtlinien für die Zulassungskontrolle

Zugangscontroller sind spezielle Richtlinien in Kubernetes. Sie bewerten API-Anfragen, um zu entscheiden, ob sie zugelassen oder geändert werden sollten. Sie sind im Grunde Torwächter. Sie setzen bestimmte Standards oder Sicherheitspraktiken im gesamten Cluster durch, bevor eine API-Anfrage bearbeitet werden kann.

Admission Controller-Richtlinien können beispielsweise:

• Automatische Durchsetzung von Ressourcenbeschränkungen

• Hinzufügen von Labels zu Bereitstellungen

• Blockieren Sie die Verwendung unsicherer Konfigurationen

Diese Art von Richtlinien kann Anfragen abfangen und ändern. Aus diesem Grund sind sie für die Aufrechterhaltung einer konsistenten Sicherheit innerhalb von Clustern von entscheidender Bedeutung. Sie beziehen sich jedoch nur auf Richtlinien im Lebenszyklus von Kubernetes-API-Aufrufen.

3. Richtlinien von OPA und Kyverno

Sind OPA- und Kyverno-Richtlinien einfach Zutrittskontrolleure, oder sind sie etwas mehr?

Open Policy Agent (OPA) und Kyverno bieten mehr als herkömmliche Zugangscontroller. Sie arbeiten zwar häufig als Zugangscontroller in Kubernetes, führen aber eine flexiblere, umfassendere Richtliniensprache ein. Auf diese Weise können Unternehmen komplexe Regeln für mehrere Systeme definieren und anwenden.

• OPA (Offener Policy-Agent) ist eine vielseitige Policy-Engine, die umgebungsübergreifend verwendet werden kann. Es verwendet eine Sprache namens Rego, die komplexe politische Anforderungen bewältigen kann. Neben Kubernetes kann OPA auch Richtlinien für CI/CD-Pipelines, Microservices und sogar Cloud-Ressourcen verwalten.

• Kywerno ist eine Policy-Engine, die speziell für Kubernetes entwickelt wurde. Es ist eine einfachere Methode, 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 kontrollieren, was Zugriff auf ein System erhält, aber sie können viel mehr für eine Reihe von Apps und Systemen tun. Sie können Folgendes verwalten:

• Lebenszyklusmanagement

• Validierung

• Benutzerdefinierte Konformitätsprüfungen

4. Ressourcenquoten und Limitpolitik

Richtlinien zur Ressourcenverwaltung helfen dabei, zu kontrollieren, wie viel CPU, Arbeitsspeicher und Speicher ein Kubernetes-Cluster verwenden kann. Diese Richtlinien sind in gemeinsam genutzten Umgebungen wichtig, da sie verhindern, dass eine App oder ein Benutzer zu viele Ressourcen verwendet.

• Kontingente werden normalerweise für jeden Namespace gesetzt. Sie begrenzen die Gesamtmenge der Ressourcen, die ein Namespace verwenden kann, sodass kein einzelner Namespace zu viel beansprucht.

• Grenzwerte definieren Sie die kleinste und größte Anzahl von Ressourcen, die ein Container oder Pod verwenden kann. Dadurch wird sichergestellt, dass kein einzelner Workload zu viele Ressourcen verbraucht und Probleme für den Rest des Systems verursacht.

Mit diesen Richtlinien können Administratoren Ressourcen ausgleichen, was besonders in Umgebungen mit vielen Benutzern oder Apps, die dynamisch skalieren, wichtig ist. Diese Richtlinien tragen zwar dazu bei, das System stabil zu halten, machen die Dinge aber auch komplizierter, da sie mit anderen Richtlinienebenen wie Automatisierung und Zugangskontrollen interagieren.

Diese Richtlinien helfen Administratoren dabei, Ressourcen auszugleichen, was besonders in Systemen mit vielen Benutzern oder Apps, die dynamisch skalieren, wichtig ist. Die Verwaltung dieser Richtlinien kann jedoch eine Herausforderung sein. Sie überschneiden sich häufig mit anderen Richtlinien wie Automatisierung und Zulassungskontrollen.

5. Sicherheitsrichtlinien für Pods (PSPs)

Pod-Sicherheitsrichtlinien (PSPs) in Kubernetes legen Sie Sicherheitskonfigurationen auf Pod-Ebene fest. Dazu gehört auch, dass Container daran gehindert werden, als Root ausgeführt zu werden, oder dass bestimmte Linux-Funktionen erforderlich sind.

Aber PSPs werden in Kubernetes schrittweise eingestellt. Sie werden durch neuere Optionen wie Pod Security Standards (PSS) und externe Tools wie OPA und Kyverno ersetzt.

PSPs wurden so konzipiert, dass sie granulare Sicherheitseinstellungen hinzufügen, die verhindern, dass Workloads mit übermäßig freizügigen Konfigurationen ausgeführt werden. Sie sind zwar nützlich, aber die Verwaltung von PSPs zusammen mit anderen Richtlinien kann verwirrend sein. Neuere Tools bieten flexiblere Möglichkeiten zur Durchsetzung von Sicherheitsvorkehrungen, häufig unter dem allgemeinen Begriff „Sicherheitsrichtlinien“.

6. Service Mesh-Richtlinien

In Microservices-Umgebungen Servicemetze wie Istio oder Linkerd fügen eine weitere Richtlinienebene hinzu, die die Kommunikation zwischen Diensten sichert und überwacht. Diese Richtlinien sind häufig:

• Authentifizieren und autorisieren Sie den Verkehr: Service Meshes verwenden mTLS (Mutual TLS), um die Kommunikation zwischen Diensten zu verschlüsseln. Sie ermöglichen es Ihnen auch, Richtlinien festzulegen, nach denen Dienste miteinander kommunizieren können, wodurch eine weitere Ebene der Zugriffskontrolle hinzugefügt wird.

• Verkehr verwalten: Service Mesh-Richtlinien steuern Routing, Load Balancing und Failover. Das macht es einfacher, Dinge wie A/B-Tests, Canary-Releases oder die Weiterleitung des Datenverkehrs an verschiedene Serviceversionen durchzuführen.

Im Gegensatz zu Netzwerkrichtlinien funktionieren Service Mesh-Richtlinien auf der Anwendungsebene und wirken sich auf die Interaktion der Dienste aus. Diese Richtlinien sind entscheidend für die Verwaltung des Datenverkehrs von Dienst zu Dienst. Sie können jedoch manchmal verwirrend sein, da sie sich mit den Netzwerkrichtlinien überschneiden.

7. Richtlinien zur Einhaltung der Vorschriften

Compliance-Richtlinien kann Datenmanagement-, Zugriffs- und Betriebsstandards abdecken, um sicherzustellen, dass Systeme gesetzliche oder interne Compliance-Anforderungen wie GDPR, HIPAA oder SOC 2 erfüllen. Diese Richtlinien können in vielen Teilen eines Systems eine wichtige Rolle spielen und sich auf Sicherheit, Protokollierung und Datenspeicherung auswirken.

Beispielsweise kann eine Compliance-Richtlinie vorschreiben, dass Daten nur an bestimmten Orten gespeichert werden (Datenresidenz) oder dass Auditprotokolle für einen bestimmten Zeitraum aufbewahrt werden. In Kubernetes werden Tools wie OPA und Kyverno häufig 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 dem Gesundheitswesen und dem Finanzwesen. Da sie in vielen Teilen eines Systems gelten und sich häufig mit Sicherheitsrichtlinien überschneiden, kann ihre Verwaltung komplex werden. Trotzdem sind sie entscheidend, um sicherzustellen, dass 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 beispielsweise Aufgaben wie die automatische Skalierung von Ressourcen, die Bereinigung ungenutzter Ressourcen oder die Verwaltung 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. Dadurch entstehen selbstverwaltende Umgebungen, 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 stehen jedoch in engem Zusammenhang mit anderen Richtlinien, z. B. denen für Ressourcenmanagement und Zutrittskontrolle, was die Komplexität erhöhen kann.

Folgst du immer noch? Die Überschneidung von „Politik“ geht weiter...

Wenn Sie noch nicht überwältigt sind, hier ist der Twist. In vielen Organisationen gibt es inzwischen Richtlinien für Richtlinien.

Diese werden „Metapolitiken“ genannt. Sie dienen als Leitplanken und legen Regeln fest, wer andere Richtlinien erstellen, verwalten oder anwenden kann.

Beispielsweise könnte eine Metarichtlinie entscheiden, welche Teams bestimmte Netzwerkrichtlinien erstellen können oder wer autorisiert ist, Zugangssteuerungsrichtlinien zu erstellen. Diese Richtlinien basieren häufig auf einer rollenbasierten Zugriffskontrolle (RBAC).

In großen Systemen RBAC-Richtlinien denn Politiken sind 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 kritische Infrastrukturen nicht überschreiten oder beeinträchtigen.

Letzte Gedanken: Ein Fahrplan für den Umgang mit politischen Überlastungen

Da Cloud-native und verteilte Umgebungen zunehmen, wird sich das Konzept der „Richtlinien“ weiter ändern. Sie werden komplizierter, spezialisierter und manchmal sogar widersprüchlicher.

Um eine Überlastung durch Richtlinien zu vermeiden, ist es wichtig, klare Benennungskonventionen zu verwenden, eine Dokumentation zu erstellen, die jeden Richtlinientyp definiert, und die Richtlinientools sinnvoll zu nutzen.

Und wenn Sie das nächste Mal auf einer Technologiekonferenz sind und „Richtlinien“ hören, nehmen Sie sich einen Moment Zeit und fragen Sie: „Welche?!“ Das könnte Sie vor einer Menge Verwirrung bewahren — oder sogar vor einem Crosshallen-Sprint!

Nehmen Sie noch heute Kontakt mit uns auf um zu erfahren, wie Illumio Ihre Netzwerksicherheitsrichtlinien in Cloud-, Endpunkt- und Rechenzentrumsumgebungen vereinfachen kann.