/
Cyber Resilience

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.

Blaue und lila Berge mit dem KubeCon-Logo

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.  

Verwandte Themen

No items found.

Verwandte Artikel

Cyber Monday: Sind Ihre situativen Kronjuwelen in dieser Weihnachtszeit geschützt?
Cyber Resilience

Cyber Monday: Sind Ihre situativen Kronjuwelen in dieser Weihnachtszeit geschützt?

Angemessener Schutz ist nicht flüchtig wie das Starbucks-Produktglossar für die Feiertage. Gute Sicherheit sollte das ganze Jahr über eingebaut und berücksichtigt werden.

Mehr Cyberangriffe, Lähmung von Zero-Trust-Analysen und Cloud-Sicherheit
Cyber Resilience

Mehr Cyberangriffe, Lähmung von Zero-Trust-Analysen und Cloud-Sicherheit

Andrew Rubin, CEO und Mitbegründer von Illumio, spricht über die Lähmung der Arbeitsbelastung und darüber, wie traditionelle Sicherheitstools den heutigen katastrophalen Angriffen nicht standhalten können

Ein Aufruf für Cyber Resilience und Zero Trust: Illumio Month im Rückblick
Cyber Resilience

Ein Aufruf für Cyber Resilience und Zero Trust: Illumio Month im Rückblick

Der Beginn des Jahres 2022 hat die erhöhte Priorität der Zero-Trust-Sicherheit in der heutigen Cyberlandschaft in den Fokus gerückt. Viele Unternehmen sehen sich mit einer weiteren Komplexität ihrer Netzwerke konfrontiert, da sich flexible Arbeitsoptionen weiterentwickeln, und eine volatile geopolitische Landschaft hat zu einem exponentiellen Anstieg internationaler Ransomware-Angriffe und -Verstöße geführt.

Die Evolution des Systemdesigns: Von schreibgeschützten Schnittstellen zur Multi-Cloud-Automatisierung
Cyber Resilience

Die Evolution des Systemdesigns: Von schreibgeschützten Schnittstellen zur Multi-Cloud-Automatisierung

Erhalten Sie Einblicke in die Entwicklung des Systemdesigns und verteilter Systeme – und die Herausforderungen und Chancen, die vor uns liegen.

Warum flexiblere Cloud-Service-Modelle kostengünstiger sind
Cyber Resilience

Warum flexiblere Cloud-Service-Modelle kostengünstiger sind

Besseres Verständnis der wirtschaftlichen Berechnungen von Public-Cloud-Anbietern und fundierte Entscheidungen über Kompromisse bei der Ressourcenallokation.

Kubernetes-Cluster-I/O ist ein großes Chaos – aber Hilfe ist auf dem Weg
Cyber Resilience

Kubernetes-Cluster-I/O ist ein großes Chaos – aber Hilfe ist auf dem Weg

Erfahren Sie mehr über die Verbreitung von Kubernetes-Cluster-I/O und die Bemühungen, die unternommen werden, um die Landschaft zu vereinfachen.

Gehen Sie von einer Sicherheitsverletzung aus.
Minimieren Sie die Auswirkungen.
Erhöhen Sie die Resilienz.

Sind Sie bereit, mehr über Zero Trust-Segmentierung zu erfahren?