Kubernetes NetworkPolicy: Default Deny blockiert auch DNS

Eine Kubernetes NetworkPolicy mit leerem podSelector und policyTypes: [Ingress, Egress] isoliert alle Pods eines Namespace in beiden Richtungen. Eine vollständige Egress-Sperre unterbricht auch DNS, wie die Kubernetes-Referenz zu NetworkPolicy ausdrücklich festhält. Für einen kontrollierten Rollout prüfen Sie zuerst das Netzwerk-Plugin, erfassen benötigte Verbindungen, definieren Freigaben für DNS und Anwendungen und erproben Default Deny in einem Test-Namespace.

Die Beispiele verwenden die portable API networking.k8s.io/v1 und den hypothetischen Namespace app-test, den Sie vor dem Anwenden anlegen. Jede der kompakten Zeilen ist ein eigenständiges YAML-Objekt in Flow-Schreibweise: Speichern Sie sie jeweils in einer Datei und wenden Sie diese mit kubectl apply -f DATEI an. Beachten Sie schon jetzt: Auch eine einzelne Freigaberegel isoliert die von ihr ausgewählten Pods bereits in der angegebenen Richtung, sobald das Plugin sie durchsetzt. Die Einschränkung beginnt nicht erst mit der abschließenden Default-Deny-Regel.

Vor dem ersten Policy-Objekt: CNI und Verkehrswege prüfen

Ein erfolgreiches kubectl apply beweist keine Filterwirkung. Ermitteln Sie beim Clusterbetreiber oder in der Clusterkonfiguration, welches Netzwerk-Plugin die Policies durchsetzt und ob es sowohl Ingress als auch Egress unterstützt. Prüfen Sie dies in einem entbehrlichen Namespace mit zwei Test-Pods: Sperren Sie den Eingang zum Ziel-Pod, versuchen Sie eine neue Verbindung von einem anderen Pod und entfernen Sie die Testregel danach wieder. Bleibt der Weg offen, ist die Ursache zunächst beim Plugin oder seiner Konfiguration zu klären.

Erfassen Sie dann für jede Anwendung die tatsächlich genutzten Quellen, Ziele, Protokolle und Ports. Für Verbindungen innerhalb des Clusters gehören dazu Pod- und Namespace-Labels auf beiden Seiten; für ausgehende Ziele außerhalb des Clusters die benötigten IP-Bereiche und Dienste. Berücksichtigen Sie auch Startvorgänge, Hintergrundjobs und Telemetrie, weil ein bloßer Test des Hauptaufrufs diese Wege übersieht. Ein Service-Name ist kein auswählbarer Peer einer portablen NetworkPolicy: Regeln wählen Pods und Namespaces über Labels oder externe IP-Blöcke aus.

DNS-Ausnahme auf den tatsächlichen Resolver zuschneiden

Eine Namensabfrage braucht eine eigene Egress-Freigabe. Das Calico-Tutorial zur DNS-Freigabe zeigt, dass nslookup nach Egress-Isolation scheitert und mit einer passenden Regel für den DNS-Dienst wieder funktioniert. Das bedingte Beispiel unten erlaubt UDP und TCP auf Port 53 zu DNS-Pods im Namespace kube-system; es setzt deren Label k8s-app=kube-dns voraus.

Lesen Sie dafür in einem betroffenen Pod /etc/resolv.conf und vergleichen Sie die dort genannte Resolver-Adresse mit den DNS-Services und Endpunkten des Clusters. Mit kubectl get pods -n kube-system --show-labels lässt sich der angenommene Pod-Selektor prüfen. Der standardisierte Namespace-Labelschlüssel kubernetes.io/metadata.name begrenzt den Peer auf kube-system, der zusätzliche podSelector auf die passenden DNS-Pods. Stimmen Resolver, Namespace oder Labels nicht überein, muss die Regel entsprechend angepasst werden.

{apiVersion: networking.k8s.io/v1, kind: NetworkPolicy, metadata: {name: allow-dns-egress, namespace: app-test}, spec: {podSelector: {}, policyTypes: [Egress], egress: [{to: [{namespaceSelector: {matchLabels: {kubernetes.io/metadata.name: kube-system}}, podSelector: {matchLabels: {k8s-app: kube-dns}}}], ports: [{protocol: UDP, port: 53}, {protocol: TCP, port: 53}]}]}}

Diese Policy wählt alle Anwendungs-Pods in app-test für Egress aus. Sobald sie greift, sind andere ausgehende Verbindungen dieser Pods nur noch erlaubt, wenn weitere Egress-Policies sie freigeben. Erproben Sie die Regel deshalb zusammen mit den benötigten Anwendungsfreigaben im Test-Namespace; eine allein vorgezogene DNS-Regel kann laufende Zugriffe auf Datenbanken oder externe Dienste abschneiden.

Ingress und Egress für die Anwendung öffnen

Im bedingten Beispiel trägt der aufrufende Pod app=frontend, der Ziel-Pod app=api; die API nimmt TCP-Verbindungen auf Port 8080 an. Die erste Regel erlaubt dem Frontend Egress zum API-Pod, die zweite Ingress am API-Pod vom Frontend. Ersetzen Sie Labels und Port durch die Werte Ihrer Anwendung und fügen Sie weitere tatsächlich benötigte Wege als eigene Freigaben hinzu.

{apiVersion: networking.k8s.io/v1, kind: NetworkPolicy, metadata: {name: allow-frontend-egress, namespace: app-test}, spec: {podSelector: {matchLabels: {app: frontend}}, policyTypes: [Egress], egress: [{to: [{podSelector: {matchLabels: {app: api}}}], ports: [{protocol: TCP, port: 8080}]}]}}

{apiVersion: networking.k8s.io/v1, kind: NetworkPolicy, metadata: {name: allow-api-ingress, namespace: app-test}, spec: {podSelector: {matchLabels: {app: api}}, policyTypes: [Ingress], ingress: [{from: [{podSelector: {matchLabels: {app: frontend}}}], ports: [{protocol: TCP, port: 8080}]}]}}

Die Peer-podSelectoren in diesen beiden Regeln beziehen sich auf app-test. Soll ein Pod in einem anderen Namespace erreicht werden, braucht derselbe Peer zusätzlich einen passenden namespaceSelector. Ist die Quellseite für Egress und die Zielseite für Ingress isoliert, müssen beide Richtungen den Verbindungsaufbau erlauben; Antwortpakete einer erlaubten Verbindung sind implizit zugelassen. Bei Zugriff über eine Service-IP prüfen Sie den tatsächlichen Datenweg, denn die Reihenfolge von Adressumschreibung und Policy-Auswertung kann je nach Implementierung variieren.

Default Deny erst nach dem Test der Freigaben setzen

Der Calico-Leitfaden zum Default Deny empfiehlt für globale Sperren vorbereitete Freigaben, eine Erprobung in Staging und den Ausschluss von System-Namespaces. Hier bleibt die Regel auf app-test beschränkt und nutzt ausschließlich die Kubernetes-API. Calicos GlobalNetworkPolicy ist eine separate Erweiterung und gehört nicht in dieses portable Beispiel.

{apiVersion: networking.k8s.io/v1, kind: NetworkPolicy, metadata: {name: default-deny, namespace: app-test}, spec: {podSelector: {}, policyTypes: [Ingress, Egress]}}

Der leere podSelector erfasst alle Pods im Namespace; ohne ingress- und egress-Listen erlaubt diese Policy selbst keine Verbindung. Die zuvor angelegten Regeln bleiben wirksam, weil Kubernetes die erlaubten Wege passender Policies addiert und keine Priorität aus der Reihenfolge der Objekte ableitet. Im Test-Namespace gehören daher DNS-, Anwendungs- und Default-Deny-Regeln zum selben erprobten Satz. Auch eine breit gefasste bestehende Freigabe muss geprüft werden: Ein dauerhaftes allow-all für Egress würde die beabsichtigte Egress-Sperre aufheben.

Für einen bestehenden produktiven Namespace ist das Anlegen der Freigaben noch kein risikofreier Vorlauf: Jede solche Regel kann ihre ausgewählten Pods unmittelbar isolieren. Planen Sie den Übergang deshalb als kontrollierte Änderung mit vollständig erfassten Abhängigkeiten und einem Rückweg für die neuen Policies. Ein erfolgreiches Anlegen der Objekte sagt zudem nicht, wann das Netzwerk-Plugin sie auf allen Knoten durchgesetzt hat.

Erlaubte und gesperrte Wege getrennt prüfen

Beginnen Sie mit neuen Verbindungen aus den betroffenen Pods. Eine nslookup-Abfrage für einen internen Service muss eine Antwort liefern; danach muss der Frontend-Pod die API auf dem freigegebenen Port erreichen. Scheitert schon die Namensauflösung, vergleichen Sie Resolver-Adresse, DNS-Endpunkt, Namespace-Label und Pod-Label mit der DNS-Regel. Gelingt DNS, aber der API-Aufruf nicht, prüfen Sie die Egress-Regel am Frontend und die Ingress-Regel am API-Pod.

Ein zweiter Test muss eine bewusst nicht freigegebene Verbindung aus einem anderen Test-Pod zum API-Port blockieren. Prüfen Sie außerdem ein ausgehendes Ziel ohne Freigabe; eine erfolgreiche DNS-Auflösung allein darf diesen Zugriff nicht ermöglichen. Testen Sie nach jeder Änderung erneut mit frisch aufgebauten Verbindungen, weil das Verhalten bereits bestehender Verbindungen beim Wechsel einer Policy vom Netzwerk-Plugin abhängt. Erst wenn erlaubte und gesperrte Wege im Test-Namespace stimmen, lässt sich derselbe Regelsatz mit den tatsächlichen Labels und Zielen des Anwendungs-Namespace übernehmen.

Lesen Sie auch: