K8s Network Policy

Kubernetes NetworkPolicy YAML Sicherheitsregel-Generator

Leitfaden für die Generierung deklarativer Kubernetes NetworkPolicy-Manifeste, Zero-Trust-Pod-Isolation, Namensraum-Ingress/Egress-Regeln, CIDR-ipBlocks und Multi-Port-Spezifikationen.

Vorlagen:
Erzwungene Richtlinientypen (spec.policyTypes)
Ziel-Pod-Selektor (spec.podSelector)

Definieren Sie, welche Pods im Namespace "production" durch diese Richtlinie beschränkt werden.

Labels abgleichen (Schlüssel = Wert):
=
=
Richtlinien-Metadaten-Labels
:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-api-netpol
  namespace: production
  labels:
    tier: api
spec:
  podSelector:
    matchLabels:
      app: backend-api
      tier: api
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - # Allow HTTP from Frontend Pods
      from:
        - podSelector:
            matchLabels:
              app: web-frontend
      ports:
        - protocol: TCP
          port: 8080
    - # Allow Metrics Scraping from Monitoring Namespace
      from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: monitoring
          podSelector:
            matchLabels:
              app: prometheus
      ports:
        - protocol: TCP
          port: 9090
  egress:
    - # Allow CoreDNS Resolution in kube-system
      to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
          podSelector:
            matchLabels:
              k8s-app: kube-dns
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53
    - # Allow PostgreSQL Connection
      to:
        - podSelector:
            matchLabels:
              app: postgres
      ports:
        - protocol: TCP
          port: 5432
    - # Allow Redis Cluster Egress
      to:
        - podSelector:
            matchLabels:
              app: redis
      ports:
        - protocol: TCP
          port: 6379
Ziel-Pods
2 Label Selectors
Aktive Regeln
2 Ingress • 3 Egress (6 Ports)
Sicherheitsbewertung
100% Zero-Trust Compliant

Zero-Trust Mikrosegmentierung

Erstellen Sie RFC-konforme Kubernetes-Netzwerkrichtlinien mit präzisen Selektoren und Port-Regeln direkt im Browser.

100% Lokaler Datenschutz

Alle Cluster-Topologien, IP-Subnetze und Sicherheitsregeln verbleiben garantiert im Browser ohne Server-Uploads.

Produktionsreife GitOps-Bereitstellung

Exportiert Standard-Manifeste zusammen mit parametrisierten Helm-Vorlagen und Kustomize-Dateien.

Technische Referenz & Architektur-Leitfaden

Kubernetes NetworkPolicy Generator Entwickler-Referenz — Referenz-Leitfaden

Leitfaden für die Generierung deklarativer Kubernetes NetworkPolicy-Manifeste, Zero-Trust-Pod-Isolation, Namensraum-Ingress/Egress-Regeln, CIDR-ipBlocks und Multi-Port-Spezifikationen.

Wichtige Parameter & Steuerelemente

metadata.namestring (RFC 1123)

Eindeutiger Bezeichner für die NetworkPolicy-Ressource im Namensraum. Muss dem RFC 1123 DNS-Subdomainstandard entsprechen (Kleinbuchstaben, Ziffern, Bindestriche oder Punkte bis 253 Zeichen).

Standard: "app-network-policy"
metadata.namespacestring (DNS Label)

Zielnamensraum in Kubernetes, in dem die Richtlinie durchgesetzt wird. NetworkPolicies isolieren Pods ausschließlich innerhalb der Grenzen ihres eigenen Namensraums.

Standard: "default"
spec.podSelector.matchLabelsobject (key-value)

Schlüssel-Wert-Labels zur Selektion der Ziel-Pods. Ist matchAllPods aktiviert, wird ein leerer Selektor {} generiert, der alle Pods im Namensraum absichert.

Standard: {"app": "backend"}
spec.policyTypesstring[] (Ingress | Egress)

Legt die überwachten Datenverkehrsrichtungen fest (Ingress, Egress oder beide). Wird eine Richtung deklariert, aber keine Regel definiert, greift ein vollständiges Default-Deny.

Standard: ["Ingress"]
spec.ingress[*].from[*]array of PeerEntry

Erlaubte Ursprünge für Ingress-Verkehr. Unterstützt podSelector, namespaceSelector, kombinierte Pod- und Namespace-Selektoren (logisches UND) sowie CIDR-ipBlocks mit Ausschlussbereichen.

Standard: []
spec.ingress[*].ports[*]array of PortEntry

Zulässige Ziel-Netzwerkports und Layer-4-Protokolle (TCP, UDP, SCTP). Unterstützt numerische Ports, benannte Containerports und Portbereiche via endPort.

Standard: []
spec.egress[*].to[*].ipBlockobject (cidr, except)

CIDR-Block für ausgehende IPv4- oder IPv6-Subnetze außerhalb des Clusters, unter Ausschluss interner Cluster-IPs über das except-Array.

Standard: {"cidr": "0.0.0.0/0", "except": ["10.0.0.0/8"]}

Profi-Tipps & Best Practices

Default Deny Baseline erzwingen

Erstellen Sie eine namensraumweite Default-Deny-Richtlinie mit podSelector: {} und policyTypes: ['Ingress', 'Egress'] ohne aktive Regeln. Dies erzwingt echte Zero-Trust-Isolation und blockiert unberechtigten horizontalen Datenverkehr (Lateral Movement), bis dedizierte Freigaben existieren.

Cross Namespace Peers begrenzen

Unterscheiden Sie bei mandantenübergreifendem Datenverkehr zwischen getrennten Listenelementen (ODER-Verknüpfung) und einem gemeinsamen Peer-Objekt mit namespaceSelector und podSelector (UND-Verknüpfung). Nur letzteres beschränkt den Zugriff exakt auf markierte Ziel-Pods im Zielnamensraum.

Kube DNS Port 53 Egress erlauben

Geben Sie beim Aktivieren von Egress-Regeln stets ausgehenden UDP- und TCP-Traffic auf Port 53 für CoreDNS-Pods im Namespace kube-system frei. Ohne DNS-Egress schlägt die interne Servicenamensauflösung fehl und nachgelagerte API- sowie Datenbankaufrufe laufen in Timeouts.

Portbereiche mit EndPort bündeln

Nutzen Sie ab Kubernetes 1.22 das Feld endPort, um zusammenhängende Portbereiche (z. B. 30000 bis 32767 für WebRTC oder passive FTP-Dienste) in einem einzigen Port-Eintrag zu deklarieren, anstatt hunderte Einzelports mühsam manuell zu pflegen.

Häufige Fallstricke & Fehlerbehebung

Angewendete NetworkPolicies zeigen keine Wirkung und der Pod-Netzwerkverkehr bleibt unreguliert.

Prüfen Sie, ob das Kubernetes-Cluster ein CNI-Plugin mit aktiver NetworkPolicy-Erzwingung verwendet (z. B. Calico, Cilium oder AWS VPC CNI mit aktiviertem amazon-network-policy-controller). Einfache CNI-Plugins wie Flannel ohne Erweiterung ignorieren NetworkPolicy-Ressourcen lautlos, obwohl kubectl die Manifeste fehlerfrei anwendet.

Pods verlieren nach dem Anwenden von Egress-Regeln die DNS-Namensauflösung für interne Services.

Sobald policyTypes 'Egress' enthält, schaltet Kubernetes alle ausgehenden Verbindungen auf Default-Deny um. Fügen Sie eine explizite Egress-Regel hinzu, die UDP- und TCP-Verkehr auf Port 53 zu den CoreDNS-Pods im Namespace kube-system ('k8s-app: kube-dns') gestattet.

Die Kombination von podSelector und namespaceSelector erlaubt unerwartet Datenverkehr aus allen Pods.

Achten Sie darauf, dass 'podSelector' und 'namespaceSelector' im selben Listen-Eintrag unterhalb von 'from:' oder 'to:' definiert sind. Werden separate Bindestriche verwendet, interpretiert Kubernetes dies als logisches ODER und erlaubt Zugriff für alle Pods des Namespaces sowie alle Pods mit dem Pod-Label.

Häufig gestellte Fragen (FAQ)

Welche Kubernetes CNI-Plugins unterstützen NetworkPolicies standardmäßig?▼

Calico, Cilium, Kube-router und VMware Antrea unterstützen NetworkPolicies von Haus aus. Flannel erfordert ein ergänzendes Tool wie Calico (Canal-Setup). Cloud-Plugins wie AWS VPC CNI benötigen die Installation des Amazon Network Policy Controllers, während Azure CNI und GKE Dataplane V2 NetworkPolicies unterstützen, wenn sie bei der Clustererstellung aktiviert wurden.

Was ist der Unterschied zwischen einem leeren Ingress-Array ([]) und dem Weglassen des Ingress-Felds?▼

Wird 'Ingress' in policyTypes geführt, sperrt die Angabe von 'ingress: []' (leeres Array) sämtlichen eingehenden Verkehr vollständig (Default-Deny). Wird das Feld weggelassen oder 'ingress: [{}]' deklariert, wird eingehender Datenverkehr bedingungslos von jedem Sender erlaubt. Die YAML-Syntax muss hier zwingend exakt sein.

Können native Kubernetes NetworkPolicies Layer-7-Protokolle wie HTTP-Pfade oder Header filtern?▼

Nein. Kubernetes-eigene NetworkPolicies filtern ausschließlich auf Layer 3 (IP-Adressen und CIDR-Blöcke) und Layer 4 (TCP, UDP, SCTP). Für Layer-7-Regelwerke wie HTTP-Pfadfilterung, URL-Routing oder Header-Validierung ist der Einsatz eines Service Mesh (z. B. Istio oder Linkerd) oder CiliumNetworkPolicy-CRDs erforderlich.

Warum sollte ipBlock nicht für Pod-interne IP-Adressen im Cluster verwendet werden?▼

Laut Kubernetes-Spezifikation ist ipBlock ausschließlich für externe Netze gedacht. Pod-IPs sind ephemer und werden bei Neustarts neu vergeben. Zudem manipulieren CNI-Routing und kube-proxy-SNAT die Quell-IPs, wodurch ipBlock-Regeln für clusterinterne Pods fehlschlagen oder unvorhersehbare Ergebnisse liefern.

Wie erzeugt der Generator Helm- und Kustomize-Manifeste ohne Server-Roundtrip?▼

Der Generator führt alle Transformationen über clientseitige TypeScript-Routinen direkt im Browser aus. Aus den interaktiv gewählten Parametern werden strukturierte YAML-Dateien, Helm-Templates mit dynamischen Release-Variablen sowie kustomization.yaml-Overlays komplett lokal und ohne externe Serveranfragen gerendert.

Verwandte Werkzeuge & Dienstprogramme

Alle Werkzeuge →