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.
- Folgen Sie der Anleitung zu GKE Enterprise aktivieren.
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-NetworkPolicy
anstelle einerFQDNNetworkPolicy
. - 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
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.Starten Sie nur für Standardcluster das GKE Dataplane V2-
anetd
-DaemonSet neu:kubectl rollout restart ds -n kube-system anetd
FQDNNetworkPolicy
erstellen
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 entwedername
oderpattern
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 mehrerepattern
-Felder verwenden. Sie müssen entwedername
oderpattern
oder beides angeben.protocol: "TCP"
undport: 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.
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
- Kubernetes-Dokumentation zu Netzwerkrichtlinien lesen
- Mit Sicherheitsinformationen andere Möglichkeiten zur Verbesserung Ihrer Infrastruktur kennenlernen