Ausgehenden Pod-Traffic mithilfe von FQDN-Netzwerkrichtlinien steuern

Auf dieser Seite wird erläutert, wie Sie die ausgehende Kommunikation zwischen Pods und Ressourcen außerhalb des GKE-Clusters (Google Kubernetes Engine) mithilfe von voll qualifizierten Domainnamen (FQDN) steuern. Die benutzerdefinierte Ressource, mit der Sie FQDNs konfigurieren, ist die FQDNNetworkPolicy-Ressource.

Hinweise

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

  • Aktivieren Sie die Google Kubernetes Engine API.
    • Google Kubernetes Engine API aktivieren
  • Wenn Sie die Google Cloud CLI für diese Aufgabe verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit gcloud components update ab.

Anforderungen und Einschränkungen

Für FQDNNetworkPolicy-Ressourcen gelten die folgenden Anforderungen und Einschränkungen:

  • Sie benötigen einen GKE-Cluster, auf dem eine der folgenden Versionen ausgeführt wird:
    • 1.26.4-gke.500 oder höher
    • 1.27.1-gke.400 oder höher
  • Ihr Cluster muss GKE Dataplane V2 verwenden.
    • Sie müssen einen der DNS-Anbieter in Ihrem GKE-Cluster verwenden, kube-dns oder Cloud DNS. Benutzerdefinierte kube-dns- oder Core DNS-Deployments werden nicht unterstützt.
  • Google Cloud CLI-Version 462.0.0 oder höher.
  • Windows-Knotenpools werden nicht unterstützt.
  • Cloud Service Mesh wird nicht unterstützt.
  • Wenn Sie in Ihrer Anwendung hartcodierte IP-Adressen haben, verwenden Sie das Feld IPBlock der Kubernetes-NetworkPolicy anstelle einer FQDNNetworkPolicy.
  • Ergebnisse, die von Nicht-Cluster-DNS-Nameservern wie alternativen Nameservern in resolv.conf zurückgegeben werden, gelten nicht als gültig, um in der Zulassungsliste in der GKE-Datenebene zu programmiert werden.
  • Die maximale Anzahl von IPv4- und IPv6-IP-Adressen, zu denen ein FQDNNetworkPolicy aufgelöst werden kann, beträgt 50.
  • Sie können Traffic zu einem ClusterIP oder einem headless Dienst nicht als ausgehendes Ziel in einem FQDNNetworkPolicy zulassen, da GKE die virtuelle IP-Adresse (VIP) des Dienstes in Backend-Pod-IP-Adressen übersetzt, bevor Netzwerkrichtlinienregeln ausgewertet werden. Verwenden Sie stattdessen eine labelbasierte Kubernetes-NetworkPolicy.
  • Pro Hostname gilt ein maximales Kontingent von 100 IP-Adressen.
  • Die transparente Verschlüsselung zwischen Knoten wird von FQDN-Netzwerkrichtlinien nicht unterstützt.
  • FQDN-Netzwerkrichtlinien mit Musterabgleich stimmen nur mit Subdomains auf derselben Ebene wie der Platzhalter überein. Beispiel: pattern: *.company.com entspricht api.company.com oder store.company.com, aber nicht eu.api.company.com oder company.com.

FQDN-Netzwerkrichtlinie aktivieren

Sie können die FQDN-Netzwerkrichtlinie für einen neuen oder einen vorhandenen Cluster aktivieren.

FQDN-Netzwerkrichtlinie in einem neuen Cluster aktivieren

Erstellen Sie mit dem --enable-fqdn-network-policy-Flag einen Cluster:

gcloud container clusters create CLUSTER_NAME  \
    --enable-fqdn-network-policy

Ersetzen Sie CLUSTER_NAME durch den Namen Ihres Clusters.

FQDN-Netzwerkrichtlinie in einem vorhandenen Cluster aktivieren

  1. Aktualisieren Sie sowohl Autopilot- als auch Standardcluster mit dem Flag --enable-fqdn-network-policy:

    gcloud container clusters update CLUSTER_NAME  \
    --enable-fqdn-network-policy

    Ersetzen Sie CLUSTER_NAME durch den Namen Ihres Clusters.

  2. Starten Sie nur für Standardcluster das GKE Dataplane V2-anetd-DaemonSet neu:

    kubectl rollout restart ds -n kube-system anetd

FQDNNetworkPolicy erstellen

  1. Speichern Sie das folgende Manifest als fqdn-network-policy.yaml:

    apiVersion: networking.gke.io/v1alpha1
kind: FQDNNetworkPolicy
metadata:
  name: allow-out-fqdnnp
spec:
  podSelector:
    matchLabels:
      app: curl-client
  egress:
  - matches:
    - pattern: "*.yourdomain.com"
    - name: "www.google.com"
    ports:
    - protocol: "TCP"
      port: 443

    Dieses Manifest hat folgende Attribute:

    • name: www.google.com ist der voll qualifizierte Domainname. IP-Adressen, die vom Nameserver bereitgestellt wurden, der mit www.google.com verknüpft ist, sind zulässig. Sie müssen entweder name oder pattern oder beides angeben.
    • pattern: "*.yourdomain.com": IP-Adressen, die von Nameservern bereitgestellt werden, die diesem Muster entsprechen, sind zulässig. Sie können für den Musterschlüssel die folgenden regulären Ausdrücke verwenden: ^([a-zA-Z0-9*]([-a-zA-Z0-9_*]*[a-zA-Z0-9*])*\.?)*$. Übereinstimmungskriterien sind additiv. Du kannst mehrere pattern-Felder verwenden. Sie müssen entweder name oder pattern oder beides angeben.
    • protocol: "TCP" und port: 443: Gibt ein Protokoll und einen Port an. Wenn ein Pod versucht, mit dieser Protokoll- und Portkombination eine Verbindung zu IP-Adressen herzustellen, funktioniert die Namensauflösung, aber die Datenebene blockiert die ausgehende Verbindung. Dieses Feld ist optional.

  2. Prüfen Sie, ob Ihre Arbeitslasten von der Netzwerkrichtlinie ausgewählt werden:

    kubectl describe fqdnnp

    Die Ausgabe sieht in etwa so aus:

    Name:         allow-out-fqdnnp
Labels:       <none>
Annotations:  <none>
API Version:  networking.gke.io/v1alpha1
Kind:         FQDNNetworkPolicy
Metadata:
...
Spec:
  Egress:
    Matches:
      Pattern:  *.yourdomain.com
      Name:     www.google.com
    Ports:
      Port:      443
      Protocol:  TCP
  Pod Selector:
    Match Labels:
      App: curl-client
Events:     <none>

FQDNNetworkPolicy löschen

Sie können eine FQDNNetworkPolicy mit dem Befehl kubectl delete fqdnnp löschen:

kubectl delete fqdnnp FQDN_POLICY_NAME

Ersetzen Sie FQDN_POLICY_NAME durch den Namen Ihres FQDNNetworkPolicy.

GKE löscht die Regeln aus der Richtlinienerzwingung, aber vorhandene Verbindungen bleiben aktiv, bis sie gemäß den Richtlinien des conntrack-Standardprotokolls geschlossen werden.

Funktionsweise von FQDN-Netzwerkrichtlinien

FQDNNetworkPolicies sind nur Egress-Richtlinien, mit denen gesteuert wird, an welche Endpunkte ausgewählte Pods Traffic senden können. Ähnlich wie bei der NetworkPolicy von Kubernetes erstellt eine FQDNNetworkPolicy, die eine Arbeitslast auswählt, eine implizite Ablehnungsregel für Endpunkte, die nicht als zulässige Ziele für ausgehenden Traffic angegeben sind. FQDNNetworkPolicies können mit Kubernetes NetworkPolicies verwendet werden, wie unter FQDNNetworkPolicy und NetworkPolicy beschrieben.

FQDNNetworkPolicies werden auf IP-Adressen- und Portebene erzwungen. Sie werden nicht mithilfe von Layer-7-Protokollinformationen erzwungen (z.B. die Request-URI in einer HTTP-Anfrage). Die angegebenen Domainnamen werden mithilfe der DNS-Informationen des DNS-Anbieters des GKE-Clusters in IP-Adressen übersetzt.

DNS-Anfragen

Ein aktives FQDNNetworkPolicy, das Arbeitslasten auswählt, wirkt sich nicht auf die Fähigkeit von Arbeitslasten aus, DNS-Anfragen zu senden. Befehle wie nslookup oder dig können in allen Domains verwendet werden, ohne dass die Richtlinie betroffen ist. Nachfolgende Anfragen an die IP-Adress-Sicherungsdomains, die nicht im Zulassungsliste sind, werden jedoch verworfen.

Wenn ein FQDNNetworkPolicy beispielsweise ausgehenden Traffic zu www.github.com zulässt, sind DNS-Anfragen für alle Domains zulässig, der an eine IP-Adresse unterstützende Traffic twitter.com wird jedoch gelöscht.

TTL-Ablauf

FQDNNetworkPolicy berücksichtigt die von einem DNS-Eintrag bereitgestellte TTL. Wenn ein Pod versucht, eine abgelaufene IP-Adresse zu kontaktieren, nachdem die TTL des DNS-Eintrags verstrichen ist, werden neue Verbindungen abgelehnt. Bei langlebigen Verbindungen, deren Dauer die TTL des DNS-Eintrags überschreitet, sollten keine Trafficunterbrechungen auftreten, während Conntrack die Verbindung als noch aktiv betrachtet.

FQDN-Netzwerkrichtlinie und Netzwerkrichtlinie

Wenn sowohl FQDNNetworkPolicy als auch NetworkPolicy auf denselben Pod angewendet werden, also die Labels des Pods den in den Richtlinien konfigurierten Bedingungen entsprechen, wird ausgehender Traffic zugelassen, solange er mit einer der Richtlinien übereinstimmt. Es gibt keine Hierarchie zwischen NetworkPolicies für ausgehenden Traffic, der IP-Adressen oder Labelselektoren und FQDNNetworkPolicies angibt.

Gemeinsam genutzte Endpunkt-IP-Adressen (Load-Balancer, CDN, VPN-Gateway usw.)

Viele Domains haben keine dedizierten IP-Adressen, auf die sie verweisen, und werden stattdessen über gemeinsam genutzte IP-Adressen bereitgestellt. Dies ist besonders häufig der Fall, wenn die Anwendung von einem Load Balancer oder CDN bereitgestellt wird. Beispielsweise habenGoogle Cloud -APIs (compute.googleapis.com, container.googleapis.com usw.) keine eindeutigen IP-Adressen für jede API. Stattdessen werden alle APIs mithilfe eines gemeinsam genutzten Bereichs bereitgestellt.

Bei der Konfiguration von FQDNNetworkPolicies ist es wichtig, zu überlegen, ob die zulässigen Domains dedizierte IP-Adressen oder gemeinsam genutzte IP-Adressen verwenden. Da FQDNNetworkPolicies auf IP-Adressen- und Portebene erzwungen werden, können sie nicht zwischen mehreren Domains unterscheiden, die von derselben IP-Adresse aus erreichbar sind. Wenn Sie den Zugriff auf eine Domain zulassen, die durch eine gemeinsam genutzte IP-Adresse unterstützt wird, kann der Pod mit allen anderen von dieser IP-Adresse bereitgestellten Domains kommunizieren. Wenn Sie beispielsweise Traffic zu compute.googleapis.com zulassen, kann der Pod auch mit anderen Google Cloud APIs kommunizieren.

CNAME-Chasing

Wenn das FQDN-Objekt in der FQDNNetworkPolicy eine Domain mit CNAMEs im DNS-Eintrag enthält, müssen Sie die FQDNNetworkPolicy mit allen Domainnamen konfigurieren, die der Pod direkt abfragen kann, einschließlich aller potenziellen Aliasse, um ein zuverlässiges FQDNNetworkPolicy-Verhalten zu gewährleisten.

Wenn Ihr Pod example.com abfragt, sollten Sie example.com in die Regel schreiben. Auch wenn Sie eine Kette von Aliassen von Ihren vorgelagerten DNS-Servern zurückgeben (z. B. example.com bis example.cdn.com bis 1.2.3.4), lässt die FQDN-Netzwerkrichtlinie Ihren Traffic weiterhin zu.

Bekannte Probleme

In diesem Abschnitt werden alle bekannten Probleme bei voll qualifizierten Domainnamen (FQDNs) aufgeführt.

Wenn Sie protocol: ALL angeben, wird die Richtlinie ignoriert.

Dieses bekannte Problem wurde für die GKE-Versionen 1.27.10-gke.1055000 und höher sowie 1.28.3-gke.1055000 und höher behoben.

Wenn Sie einen FQDNNetworkPolicy erstellen, der protocol: ALL im Abschnitt ports angibt, erzwingt GKE die Richtlinie nicht. Dieses Problem tritt aufgrund eines Problems beim Parsen der Richtlinie auf. Die Angabe von TCP oder UDP verursacht dieses Problem nicht.

Wenn Sie das Problem umgehen, geben Sie im ports-Eintrag keinen protocol an. Die Regel entspricht standardmäßig allen Protokollen. Durch das Entfernen von protocol: ALL wird das Parsing-Problem umgangen und GKE erzwingt den FQDNNetworkPolicy.

In der GKE-Version 1.27.10-gke.1055000+ und 1.28.3-gke.1055000+ werden Richtlinien mit protocol: ALL korrekt geparst und erzwungen.

NetworkPolicy-Logging führt zu falschen oder fehlenden Logs

Dieses bekannte Problem wurde für die GKE-Versionen 1.27.10-gke.1055000+ und 1.28.2-gke.1157000+ behoben.

Wenn Ihr Cluster Netzwerkrichtlinien-Logging und FQDN-Netzwerkrichtlinien verwendet, liegt ein Fehler vor, der zu fehlenden oder falschen Logeinträgen führen kann.

Wenn Sie das Logging von Netzwerkrichtlinien ohne Bevollmächtigten verwenden, geben die Richtlinienlogs für DNS-Verbindungen, die eine Arbeitslast verlassen, fälschlicherweise an, dass der Traffic unterbrochen wurde. Der Traffic selbst war gemäß FQDNNetworkPolicy zulässig, die Logs waren jedoch falsch.

Wenn Sie das Logging von Netzwerkrichtlinien mit Delegierung verwenden, fehlen Richtlinienlogs. Der Traffic selbst ist davon nicht betroffen.

In GKE-Versionen 1.27.10-gke.105500+ und 1.28.2-gke.1157000+ wurde dieser Programmfehler behoben. DNS-Verbindungen werden jetzt korrekt als ALLOWED protokolliert, wenn der Traffic von einer NetworkPolicy oder FQDNNetworkPolicy ausgewählt wird.

Nächste Schritte