Risiken

Netzwerkrichtlinien in Kubernetes-Containern

Pods können ohne Einschränkungen mit Endpunkten und Diensten „kommunizieren“.

Wenn ein Container/Pod von einem Angreifer angegriffen wird, versucht der Angreifer typischerweise, auf andere Container/Pods oder den Host-Rechner zuzugreifen. Netzwerkrichtlinien verhindern diesen Versuch des Angreifers.

Wir empfehlen, in jedem Namespace eine Network Policy mit der Deny-All-Regel zu erstellen und auf sogenannte Global Network Policies zu verzichten, da diese administrativ unübersichtlich sind und ein Sicherheitsrisiko darstellen.

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

Nachdem Sie die Deny-All-Regel implementiert haben, lassen Sie alle zulässigen Kommunikationen zwischen den Pods mit weiteren Netzwerkrichtlinien wieder zu.

Wir empfehlen außerdem, dass mindestens eine Person für die Netzwerkrichtlinien zuständig ist.

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

Auch wenn die Deny-All-Regel erwähnt wird, ist es wichtig zu verstehen, welche Auswirkungen die Nichtumsetzung 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.

Verwaltungsaufwand 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.