Kubernetes Netzwerk-Richtlinie

Zero Trust, Netzwerksegmentierung

Standardmäßig ist das Kubernetes-Netzwerk nicht sicher. Der gesamte Netzwerkverkehr ist offen und alle Container sind über das Netzwerk erreichbar. Ein Container kann sich ungehindert mit jedem anderen Container im Cluster verbinden. Jeder Port ist für eingehenden und ausgehenden Datenverkehr offen.

Das ist in Ordnung, wenn Sie jedem in Ihrer Umgebung vertrauen, aber nicht so gut, wenn Ihre Umgebung von mehreren Teams in Ihrem Unternehmen gemeinsam genutzt wird. Wenn Sie einen Workload ausführen, der von externen Parteien oder aus öffentlichen und Open-Source-Repositories verwaltet wird, sollten Sie außerdem besonders vorsichtig sein und sicherstellen, dass er nur auf die Ressourcen zugreifen kann, auf die er zugreifen muss.

Um Ihre Arbeitslast vor unberechtigtem Zugriff durch "böswillige" Angreifer zu schützen, können Sie Kubernetes-Netzwerkrichtlinien verwenden, um den Netzwerkzugang zu Ihrer Arbeitslast zu sperren. Sie können sie wie eine Firewall betrachten oder mit einer Azure Network Security Group in einem virtuellen Netzwerk vergleichen.

Gemäß dem Zero Trust-Prinzip "Assume breach" sollten Sie auf Angreifer in Ihrem Clusternetzwerk vorbereitet sein. Angenommen, ein Angreifer hat Zugang, um eine bösartige Arbeitslast in Ihrem Cluster auszuführen, dann sollte er nicht in der Lage sein, eine Verbindung zu anderen Ressourcen in Ihrem Netzwerk herzustellen.

Sie sollten Ihren Workload auch vor dem Zugriff durch den benachbarten laufenden Workload schützen. Ihr Netzwerk sollte in viele kleine Segmente unterteilt sein. Für jedes Segment sollten eigene Eingangs- und Ausgangsports geöffnet werden. Datenverkehr, der nicht in das Segment hinein oder aus dem Segment heraus darf, sollte nicht zugelassen werden; Sie wollen nur Datenverkehr, den Sie ausdrücklich angeben und zulassen.

Struktur der Kubernetes-Netzwerkrichtlinien

Ohne eine Netzwerkrichtlinie ist jede Adresse und jeder Port offen. In einer Richtlinie können Sie angeben, ob Sie alle 'Ingress' oder alle 'Egress' oder beides blockieren möchten, indem Sie dies im Richtlinientyp festlegen. Der nächste Schritt besteht darin, bestimmte Ports für bestimmte Workloads zu öffnen, damit diese miteinander kommunizieren können.

Sie können dies tun, indem Sie den 'podSelector' und den 'port' in der Richtlinie angeben. Der 'podSelector' ist ein Etikettenselektor zur Angabe der Pods, für die die Richtlinie gilt. Der 'port' ist die Nummer des Ports, der geöffnet wird. Mit dem 'namespaceSelector' können Sie auch den Namespace für den Ursprung oder das Ziel des Datenverkehrs angeben.

Die Richtlinie wird in einem Kubernetes-Namensraum implementiert. Das bedeutet, dass die Richtlinie auf jeden Workload in diesem Namespace angewendet wird. Wenn Sie eine leere Richtlinie des Typs 'ingress' erstellen, bedeutet dies, dass jeder eingehende Datenverkehr blockiert wird. Sie müssen angeben, welchen Verkehr Sie zulassen möchten. Dasselbe Prinzip gilt für eine 'egress'-Richtlinie. Netzwerkrichtlinien stehen nicht im Widerspruch zueinander, sie sind additiv. Wenn Sie mehrere Richtlinien erstellen, gelten sie alle. Sie können einen Port nicht wieder schließen, der bereits durch eine andere Richtlinie geöffnet wurde.

Wie Sie eine Netzwerkrichtlinie anwenden

Wenn Sie eine Netzwerkrichtlinie in Kubernetes anwenden möchten, können Sie den Befehl kubectl apply --filename network-policy.yml verwenden. Damit wird die Netzwerkrichtlinie auf den aktiven Namespace angewendet oder der Namespace im Befehl kubectl apply --filename network-policy.yml --namespace my-namespace angegeben oder in der Definition festgelegt. Um zu überprüfen, ob die Richtlinie korrekt angewendet wurde, können Sie den Befehl kubectl describe networkpolicy verwenden.

Die folgende Beispielkonfiguration blockiert den gesamten eingehenden und ausgehenden Datenverkehr. Dadurch wird sichergestellt, dass Pods aus anderen Namespaces keine Netzwerkverbindung zu einer Workload im Namespace öffnen können. Der Workload im Namespace kann keine Netzwerkverbindung zu Ressourcen außerhalb des Namespaces öffnen.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-all
spec:
podSelector: {}
policyTypes:
- Ingress
- Egress

Da es sich bei podSelector um ein leeres Objekt handelt, gilt die Richtlinie für alle Pods im Namespace. Die policyTypes legt fest, dass sowohl der eingehende als auch der ausgehende Verkehr blockiert wird.

Beispiel-Lösung

Nehmen wir die folgende vereinfachte Beispiellösung. Wir haben einen Ingress-Controller im Namespace 'ingress-namespace' angegeben. Der Ingress-Verkehr aus dem Internet ist erlaubt und der Egress-Verkehr zum Frontend-Pod ist erlaubt. Der Frontend-Pod darf eine Verbindung zum Backend-Pod herstellen. Der Backend-Pod lässt nur Datenverkehr vom Frontend-Pod zu. Der Frontend- und der Backend-Pod befinden sich beide im 'app-namespace'. Andere Verbindungen sind nicht erlaubt und sollten durch die Netzwerkrichtlinie blockiert werden.

Wir erstellen eine Netzwerkrichtlinie für den 'ingress-namespace', um den Datenverkehr zuzulassen. Mit dem podSelector legen wir fest, dass die Richtlinie nur auf die Pods mit dem Label app: ingress-controller angewendet wird. Andere Pods in diesem Namespace werden weiterhin blockiert. Sie können bestimmte Pods durch Labels angeben oder podSelector: {} setzen, um diese Richtlinie auf alle Pods im Namensraum anzuwenden.

Im Abschnitt Ingress geben wir an, von welcher IP-Adresse der eingehende Datenverkehr blockiert werden darf, in diesem Fall jede IP-Adresse der Welt, indem wir den Bereich 0.0.0.0/0 verwenden. Im Bereich Ports geben wir den Port 443 an, um nur HTTPS-Verkehr zuzulassen.

Für den Egress werden der NamespaceSelector und der PodSelector verwendet, um den Frontend-Pod über das Label app=frontend in der app-namespace zu spezifizieren. Der NamespaceSelector arbeitet nur mit Labels und nicht mit dem Namen des Namespaces. Kubernetes wendet automatisch ein Label kubernetes.io/metadata.name an, wenn Sie einen neuen Namespace erstellen. Sie können dieses Label verwenden oder dem Namespace Ihr eigenes Label hinzufügen. Jetzt ist also nur noch ausgehender Datenverkehr zum Frontend-Pod im App-Namensraum auf Port 8443 erlaubt.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-ingress-namespace
namespace: ingress-namespace
spec:
podSelector:
matchLabels:
app: ingress-controller
policyTypes:
- Ingress
- Egress
ingress:
- from:
- ipBlock:
cidr: 0.0.0.0/0
ports:
- port: 443
egress:
- to:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: app-namespace
podSelector:
matchLabels:
app: frontend
ports:
- port: 8443

Für den 'app-namespace' erstellen wir eine Netzwerkrichtlinie, um den eingehenden Datenverkehr zuzulassen. Diese Richtlinie gilt nur für Pods mit dem Label app=frontend. Sie erlaubt eingehenden Datenverkehr von den Ingress-Controller-Pods im Ingress-Namespace. Nur Port 8443 wird geöffnet.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-ingress-frontend
namespace: app-namespace
spec:
podSelector:
matchLabels:
app: frontend
policyTypes:
- Ingress
ingress:
- from:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: ingress-namespace
- podSelector:
matchLabels:
app: ingress-controller
ports:
- port: 8443

Die folgende Richtlinie erlaubt den ausgehenden Datenverkehr vom Frontend zum Backend-Pod. Der eingehende Datenverkehr auf dem Backend-Pod wird dadurch nicht automatisch zugelassen. Dies sollte in einer anderen Richtlinie festgelegt werden.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-egress-frontend
namespace: app-namespace
spec:
podSelector:
matchLabels:
app: frontend
policyTypes:
- Egress
egress:
- to:
- podSelector:
matchLabels:
app: backend
ports:
- port: 8080

Und die Richtlinie, um den eingehenden Datenverkehr auf dem Backend-Pod zuzulassen. Dadurch wird der gesamte andere eingehende Datenverkehr blockiert, so dass keine anderen Pods eine direkte Verbindung zum Backend-Pod herstellen können.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-ingress-backend
namespace: app-namespace
spec:
podSelector:
matchLabels:
app: backend
policyTypes:
- Ingress
ingress:
- from:
- podSelector:
matchLabels:
app: frontend
ports:
- port: 8080

Mit diesen Richtlinien, die auf den Kubernetes-Cluster angewendet wurden, haben wir den gesamten unerwünschten Netzwerkverkehr blockiert. Wir haben den fein abgestuften Zugriff von bestimmten Workloads auf bestimmte Workloads über bestimmte Ports erlaubt. Der gesamte andere Datenverkehr wird blockiert. Dies schützt Ihre Workloads vor unbefugtem und unerwünschtem Zugriff über das Netzwerk. Viel Spaß beim Sichern Ihres Kubernetes-Clusters!

Lektion 1: Mehrere Arbeitslasten im gleichen Namensraum

Wenn Sie mehrere Workloads im selben Namensraum laufen haben, sollten Sie dies beachten. Wenn Sie eine Richtlinie bereitstellen, wird die Definition auf alle Arbeitslasten in diesem Namensraum angewendet. Wenn Sie also eine Richtlinie zur Deaktivierung des Ingress anwenden, wird sie für alle Workloads in diesem Namespace deaktiviert, es sei denn, Sie lassen sie für diese Workloads ausdrücklich wieder zu.

Lektion 2: DNS-Anfragen

Wenn Sie die Netzwerkrichtlinie zum Blockieren des gesamten ausgehenden Datenverkehrs anwenden, werden auch die DNS-Anfragen blockiert. Selbst wenn Sie Ihrem Pod erlauben, eine Verbindung z.B. zu https://www.xebia.com herzustellen, kennt der Pod die IP-Adresse dieser Website nicht. Um die IP-Adresse der Website zu erhalten, fragt der Pod den internen DNS-Server, der im Cluster läuft, nach der IP-Adresse. Diese Anfragen erfolgen über Port 53. Wenn Sie den gesamten ausgehenden Datenverkehr blockieren, blockieren Sie auch die DNS-Anfrage. Um die DNS-Anfrage zuzulassen, müssen Sie den Port in der Netzwerkrichtlinie öffnen.

DNS aktivieren

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: enable-dns-network-policy
spec:
policyTypes:
- Egress
egress:
- to:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: kube-system
podSelector:
matchLabels:
k8s-app: kube-dns
ports:
- port: 53
protocol: UDP

TIPP 1: Netzwerkrichtlinien-Editor

Zur Unterstützung bei der Erstellung Ihrer ersten Netzwerkrichtlinie können Sie den Network Policy Editor für Kubernetes unter https://app.networkpolicy.io/ verwenden. Diese App visualisiert die Richtlinienkonfigurationen und ermöglicht es Ihnen, die möglichen Regeln, die Sie angeben können, besser zu verstehen. Sie visualisiert die von Ihnen festgelegten Regeln und liefert Ihnen die korrekte yaml-Definition, ein hilfreiches Tool, um die verschiedenen Einstellungen der komplexen Netzwerkrichtlinien-Definition zu verstehen.

 

TIPP 2: Kubernetes Netzwerkrichtlinien-Rezepte

Auf https://github.com/ahmetb/kubernetes-network-policy-recipes finden Sie eine Vielzahl von Beispielen für Netzwerkrichtlinien. Sie können diese Beispiele verwenden, um Ihre eigene Richtlinie zu erstellen und sie als Ausgangspunkt für Ihre eigene Richtlinie zu verwenden.

 

HINWEIS: Unterstützte Netzwerkrichtlinien-Manager für Azure Kubernetes Services (AKS)

Dieser Artikel beschreibt Netzwerkrichtlinien für Kubernetes. Die Netzwerkrichtlinien-Engine ist für die Durchsetzung der Netzwerkrichtlinien verantwortlich. Azure Kubernetes Services (AKS) unterstützt mehrere Netzwerkrichtlinien-Engines.

- Keine

Ohne eine Netzwerkrichtlinien-Engine wird die angewandte Netzwerkrichtlinie nicht verwendet. Wenn Sie eine Richtlinie, aber keine Richtlinien-Engine einsetzen, passiert nichts und der gesamte Datenverkehr ist weiterhin offen.

- Azure Netzwerkrichtlinien-Manager

Der Azure Network Policy Manager ist eine von Microsoft verwaltete Netzwerkrichtlinien-Engine. Er verwendet die Kubernetes-Netzwerkrichtlinien-Definition, um die Netzwerkrichtlinien durchzusetzen. Es handelt sich um eine einfache Netzwerkrichtlinien-Engine, die nicht alle Funktionen der anderen Engines unterstützt, aber ein guter Ausgangspunkt für einfache Netzwerkrichtlinien ist.

- Wimper

Microsoft empfiehlt^1 Cilium als seine bevorzugte Netzwerkrichtlinien-Engine für AKS. Es ist die funktionsreichste Engine und wird von Microsoft aktiv unterstützt und gepflegt. Sie bietet Unterstützung für die Filterung nach FQDN oder HTTP-Methoden. Eine globale Netzwerkrichtlinie (CiliumClusterwideNetworkPolicy) zur Festlegung von Nicht-Namespaces und damit von Richtlinien für den Cluster-Bereich ist ebenfalls möglich. Zur Beobachtung des Netzwerks bietet es die Hubble UI zur Visualisierung des Netzwerkverkehrs.

- Kattun

Die andere Out-of-the-Box-Lösung für AKS ist Calico. Sie wird von Tigera entwickelt und unterstützt Linux- und Windows Server-Knoten. Die Art und Weise, wie Richtlinien festgelegt werden, ist fortschrittlicher als die Definition von Kubernetes-Netzwerkrichtlinien. Es verfügt über globale Netzwerkrichtlinien (GlobalNetworkPolicy), um Richtlinien für Nicht-Namespaces und Cluster-Umfang festzulegen. Die Basisversion unterstützt jedoch keine Filterung nach FQDN oder HTTP-Methoden.

- BYOCNI

BYOCNI steht für Bring Your Own Container Network Interface. Es ermöglicht Ihnen die Bereitstellung eines AKS-Clusters ohne vorinstalliertes CNI-Plugin. Sie können jedes CNI-Plugin eines Drittanbieters wie Cilium, Flannel und Weave installieren und deren Implementierung von Netzwerkrichtlinien verwenden. Der Nachteil ist, dass Sie das CNI-Plugin und den Richtlinienmanager selbst verwalten müssen.

 

Dieser Artikel ist Teil von XPRT.#17. Laden Sie das Magazin hier herunter.