Das Problem: Egress zu Cloud-Diensten mit wechselnden IPs

Dein Cluster muss nach außen reden: zu einer verwalteten Cloud-API, einem CDN, einem SaaS-Endpunkt. Du willst diesen Egress-Traffic einschränken, nicht offen lassen. Das Problem: Die IP-Adressen dieser Dienste rotieren. Du schreibst eine CIDR-Range in deine NetworkPolicy, der Anbieter wechselt den Adressbereich, und entweder bricht die Regel oder du hast von Anfang an einen viel zu großen Bereich freigegeben, nur um auf der sicheren Seite zu sein. Beide Ergebnisse sind falsch: löchrige Freigabe oder ständig kaputte Regeln, die am Ende niemand mehr pflegt.

Wo Standard-Kubernetes-NetworkPolicy aufhört

Im Beitrag Kubernetes NetworkPolicies: Warum dein Cluster offen ist vom 2. September 2026 steht die Grenze klar benannt: „Sie kennt keine Workload-Identität, keine Verschlüsselung zwischen Pods und keine Layer-7-Regeln wie ’nur GET-Requests auf /api/orders erlauben‘.“ NetworkPolicy arbeitet auf Layer 3 und 4, also mit IP-Adressen, Namespaces und Ports. Einen Domainnamen als Ziel kennt das Standard-API-Objekt nicht. Für internen Traffic zwischen Pods reicht das, weil Pod-IPs und Label-Selektoren stabil genug sind. Für Egress zu einem externen Dienst mit wechselnder IP reicht es nicht, weil die Policy IP-Adressen referenzieren muss, die sich morgen schon geändert haben können.

Cilium: DNS-Namen als Policy-Ziel statt IP-Bereiche

Cilium erweitert das Policy-Modell um einen eigenen Regeltyp: toFQDNs. Statt eine CIDR-Range anzugeben, trägst du den Domainnamen ein, zu dem Egress erlaubt sein soll. Cilium löst intern auf, welche IP-Adressen aktuell zu diesem Namen gehören, und hält diese Zuordnung aktuell, ohne dass du die Policy bei jedem IP-Wechsel anfassen musst. Die Workload-Identität bleibt bei Labels und Endpoint-Selektoren, das Egress-Ziel wird über den Namen statt über die Adresse definiert.

Der Mechanismus dahinter: ein DNS-Proxy pro Endpoint

Laut Cilium-Dokumentation zur DNS-basierten Policy fängt Cilium DNS-Antworten pro Endpoint über einen DNS-Proxy ab. Jede Antwort, die zu einem in toFQDNs konfigurierten matchName oder matchPattern passt, wird in eine interne, CIDR-basierte Regel für genau diesen Endpoint übersetzt. Erlaubt ist damit nicht „irgendeine IP, die mal zu diesem Namen gehörte“, sondern die IP, die der Pod gerade selbst per DNS aufgelöst hat. Technisch setzt das voraus, dass der L7-Proxy des Cilium-Agents aktiv ist und die Policy eine DNS-Regel für Port 53 enthält, sonst sieht Cilium die Auflösung nicht.

Eine CiliumNetworkPolicy mit toFQDNs

Ein minimales Beispiel für Egress zu einem konkreten Hostnamen und einer Wildcard-Domain:

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "to-fqdn-example"
  namespace: billing
spec:
  endpointSelector:
    matchLabels:
      app: billing-worker
  egress:
    - toEndpoints:
        - matchLabels:
            "k8s:io.kubernetes.pod.namespace": kube-system
            "k8s:k8s-app": kube-dns
      toPorts:
        - ports:
            - port: "53"
              protocol: ANY
          rules:
            dns:
              - matchPattern: "*"
    - toFQDNs:
        - matchName: "api.example-saas.com"
        - matchPattern: "*.cilium.io"

Der erste Egress-Eintrag erlaubt DNS-Auflösung über CoreDNS, der zweite erlaubt Traffic zu den beiden FQDN-Zielen. Laut Dokumentation dürfen toFQDNs-Regeln selbst keine weiteren L3-Ziele wie toEndpoints oder toCIDR in derselben Regel enthalten, L4- und L7-Einschränkungen über toPorts sind zusätzlich erlaubt.

matchName und matchPattern: wo Wildcards aufhören

matchName verlangt den exakten Domainnamen. matchPattern erlaubt ein Sternchen als Platzhalter, aber laut Dokumentation steht * nur für null oder mehr gültige Zeichen und nicht für den Punkt. *.cilium.io passt deshalb nicht auf cilium.io selbst, sondern nur auf Subdomains davon. Erlaubte Zeichen in einem Muster sind laut Dokumentation auf a bis z, 0 bis 9, Punkt und Bindestrich beschränkt. Willst du sowohl die Apex-Domain als auch Subdomains erlauben, brauchst du beide Einträge, matchName für die Apex-Domain und matchPattern für die Subdomains.

Eine Grenze, die in der Praxis auffällt

Cilium cacht pro Endpoint und FQDN standardmäßig bis zu 50 IP-Adressen, laut Dokumentation konfigurierbar über die Agent-Option --tofqdns-endpoint-max-ip-per-hostname. Ist das Limit erreicht, verfallen die ältesten Einträge automatisch, laufende Verbindungen werden dabei nicht aktiv beendet. Bei Diensten, die sehr viele IPs hinter einem Namen rotieren, lohnt sich ein Blick auf diesen Wert, bevor eine erwartete Verbindung ins Leere läuft.

Fazit: Identität statt Adresse, aber mit Voraussetzungen

FQDN-Policies lösen genau das Problem, an dem reine L3/L4-NetworkPolicy für Egress zu Cloud-Diensten scheitert: Der Domainname bleibt stabil, auch wenn die IP dahinter wechselt. Das kostet eine zusätzliche Voraussetzung, die DNS-Egress-Regel auf Port 53 mit aktivem L7-Proxy, und ein paar Regeln zu Wildcards und Cache-Größe, die du kennen musst, bevor du dich darauf verlässt. Für Egress-Allowlists auf Basis von Domainnamen statt grober CIDR-Blöcke ist das trotzdem die genauere Grundlage.

Bei Fragen zur Umsetzung in deinem Cluster schreib mir an mm@mhm-dl.de.

Über das Anmeldeformular für den Newsletter trägst du deine E-Mail-Adresse ein, kreuzt die Einwilligung an und bestätigst die Anmeldung danach per Mail. Mit der Anmeldung willigst du ein, dass der Newsletter unter anderem folgende Themen behandelt: Schulungen zu Docker, Kubernetes, CI/CD, Git-Workflows und DevSecOps-Werkzeugen sowie die Anforderungen aus NIS2, CRA und DORA und deren technische Umsetzung.