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:

  • Ein GKE-Cluster muss eine der folgenden Versionen ausführen:
    • 1.26.4-gke.500 oder höher
    • 1.27.1-gke.400 oder höher
  • Der Cluster muss GKE Dataplane V2 verwenden.
  • Sie müssen einen der DNS-Anbieter in Ihrem GKE-Cluster, kube-dns oder Cloud DNS verwenden. Benutzerdefinierte kube-dns- oder Core DNS-Bereitstellungen werden nicht unterstützt.
  • Google Cloud CLI-Version 462.0.0 oder höher.
  • Windows-Knotenpools werden nicht unterstützt.
  • Anthos Service Mesh wird nicht unterstützt.
  • Wenn Sie in Ihrer Anwendung hartcodierte IP-Adressen haben, verwenden Sie das Feld IPBlock der Kubernetes-NetworkPolicyanstelle 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 monitorlosen 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-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 den Cluster mit dem Flag --enable-fqdn-network-policy:

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 für Autopilot- und Standardcluster den Cluster 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. Sie können 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, über diese Kombination aus Protokoll und Port eine Verbindung zu IP-Adressen herzustellen, funktioniert die Namensauflösung, die Datenebene blockiert jedoch die ausgehende Verbindung. Dieses Feld ist optional.

  2. Prüfen Sie, ob die Netzwerkrichtlinie Ihre Arbeitslasten auswählt:

    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

Mit dem Befehl kubectl delete fqdnnp können Sie einen FQDNNetworkPolicy 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. Vorhandene Verbindungen bleiben jedoch aktiv, bis sie gemäß den Conntrack-Standardprotokollrichtlinien geschlossen werden.

Funktionsweise von FQDN-Netzwerkrichtlinien

FQDNNetworkPolicies sind Richtlinien für ausgehenden Traffic, die steuern, 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 Protokollinformationen der Ebene 7 erzwungen (z.B. Request-URI in einer HTTP-Anfrage). Die angegebenen Domainnamen werden mithilfe der DNS-Informationen vom DNS-Anbieter 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 gilt insbesondere, wenn die Anwendung von einem Load-Balancer oder CDN bereitgestellt wird. Beispielsweise haben Google 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-Adresse und Portebene erzwungen werden, können sie nicht zwischen mehreren Domains unterscheiden, die von derselben IP-Adresse bereitgestellt werden. 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 an 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