Risiken

Network-Policies in Kubernetes-Containern

Pods können mit End-Points und Services ohne weitere Einschränkungen kommunizieren.

Wird ein Container oder Pod angegriffen, versucht der Angreifer für gewöhnlich auf andere Container oder Pods oder auf die Maschine selbst zuzugreifen. Network-Policies wirken diesem Angriffsversuch entgegen.

Wir raten an, eine Network-Policy mit der „Deny-All“-Rolle in jedem Namespace zu erstellen und gleichermaßen von der Nutzung sogenannter globaler Network-Policies abzusehen. Oft sind diese aus administrativer Sicht verwirrend und stellen ein Sicherheitsrisiko dar.

  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: deny-all
    namespace: default ### should be created for all namespaces!
 spec:
    podSelector: {}
    policyTypes:
    - Ingress
    - Egress

Mithilfe von erweiterten Network-Policies ist den Pods die Kommunikation erneut zu gestatten.

Wir empfehlen zumindest einen Verantwortlichen für die Network-Policies zu wählen.

Bedeutung der Deny-All-Regel und Risiken der uneingeschränkten Kommunikation

Auch wenn die Deny-All-Regel erwähnt wird, ist es wichtig zu verstehen, welche Auswirkungen die Nichtimplementierung dieser Regel hat:

Exposition gegenüber sensiblen Diensten: Ohne eine Deny-All-Regel können alle Pods innerhalb des Clusters frei miteinander kommunizieren. Diese offene Kommunikation kann dazu führen, dass sensible Dienste oder Datenspeicher für potenziell gefährdete Pods zugänglich sind. Ein Angreifer, der sich Zugang zu einem Pod verschafft, kann diese uneingeschränkte Kommunikation ausnutzen, um andere Dienste zu untersuchen und auf sie zuzugreifen, was zu Datenverletzungen oder unbefugter Datenmanipulation führt.

Seitliche Bewegung: Wenn es keine restriktiven Netzwerkrichtlinien gibt, kann sich ein Angreifer seitlich innerhalb des Clusters bewegen. Sobald er sich in einem kompromittierten Pod befindet, kann der Angreifer problemlos versuchen, auf andere Pods und Dienste zuzugreifen, wodurch sich die Wahrscheinlichkeit erhöht, dass weitere Ressourcen innerhalb des Clusters kompromittiert werden.

Sicherheitsrisiko durch Standardeinstellungen: Kubernetes-Cluster verfügen häufig über Standardeinstellungen, die eine uneingeschränkte Pod-zu-Pod-Kommunikation ermöglichen. Diese Standardkonfiguration stellt ein erhebliches Sicherheitsrisiko dar, da sie nicht das Potenzial kompromittierter Pods berücksichtigt, die versuchen, Netzwerkverbindungen auszunutzen.

Administrativer Overhead und Verwirrung: Globale Netzwerkrichtlinien scheinen zwar bequem zu sein, können aber zu administrativer Verwirrung und erhöhten Sicherheitsrisiken führen. Sie können versehentlich Kommunikationspfade zulassen, die eigentlich eingeschränkt werden sollten, was zu potenziellen Sicherheitslücken führt. Durch die Erstellung von Namespace-spezifischen Deny-All-Richtlinien können Sie klarere und besser verwaltbare Sicherheitsgrenzen einhalten.

Durch die Implementierung der Deny-All-Regel stellen Sie sicher, dass nur ausdrücklich erlaubte Kommunikationen innerhalb Ihres Clusters stattfinden können. Dieser Ansatz reduziert die Angriffsfläche erheblich und mindert die Risiken, die mit offenen Kommunikationsrichtlinien verbunden sind, und verbessert so die allgemeine Sicherheitslage Ihrer Kubernetes-Umgebung.