Contrôler le trafic de sortie du pod à l'aide des règles de réseau FQDN

Cette page explique comment contrôler la communication de sortie entre les pods et les ressources en dehors du cluster Google Kubernetes Engine (GKE) à l'aide de noms de domaine complets (FQDN). La ressource personnalisée que vous utilisez pour configurer les noms de domaine complets (FQDN) est la ressource FQDNNetworkPolicy.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

  • Activez l'API Google Kubernetes Engine.
    • Activer l'API Google Kubernetes Engine
  • Si vous souhaitez utiliser Google Cloud CLI pour cette tâche, installez puis initialisez gcloud CLI. Si vous avez déjà installé gcloud CLI, assurez-vous de disposer de la dernière version en exécutant la commande gcloud components update.

Conditions requises et limites

Les ressources FQDNNetworkPolicy présentent les exigences et limitations suivantes :

  • Un cluster GKE doit exécuter l'une des versions suivantes :
    • 1.26.4-gke.500 ou version ultérieure
    • 1.27.1-gke.400 ou version ultérieure
  • Votre cluster doit utiliser GKE Dataplane V2.
  • Vous devez utiliser l'un des fournisseurs DNS de votre cluster GKE, kube-dns ou Cloud DNS. Les déploiements kube-dns personnalisés ou Core DNS ne sont pas pris en charge.
  • Google Cloud CLI version 462.0.0 ou ultérieure.
  • Les pools de nœuds Windows ne sont pas pris en charge.
  • Anthos Service Mesh n'est pas pris en charge.
  • Si vous avez des adresses IP codées en dur dans votre application, utilisez le champ IPBlock de l'objet Kubernetes NetworkPolicy plutôt que FQDNNetworkPolicy.
  • Les résultats renvoyés par des serveurs de noms DNS hors cluster, tels que des serveurs de noms alternatifs dans resolv.conf, ne sont pas considérés comme valides pour être programmés dans la liste d'autorisation du plan de données GKE.
  • Le nombre maximal d'adresses IPv4 et IPv6 qu'un FQDNNetworkPolicy peut résoudre est de 50.
  • Vous ne pouvez pas autoriser le trafic vers un service ClusterIP ou sans adresse IP de cluster en tant que destination de sortie dans un FQDNNetworkPolicy, car GKE traduit l'adresse IP virtuelle (VIP) du service en adresses IP des pods de backend avant d'évaluer les règles de stratégie réseau. Utilisez plutôt un objet NetworkPolicy basé sur les libellés Kubernetes.
  • Le quota maximal est de 100 adresses IP par nom d'hôte.
  • Le chiffrement transparent entre les nœuds n'est pas compatible avec les règles de réseau FQDN.

Activer la règle de réseau FQDN

Vous pouvez activer la règle de réseau FQDN sur un cluster nouveau ou existant.

Activer la règle de réseau FQDN dans un nouveau cluster

Créez votre cluster à l'aide de l'option --enable-fqdn-network-policy:

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

Remplacez CLUSTER_NAME par le nom de votre cluster.

Activer la règle de réseau FQDN dans un cluster existant

  1. Pour les clusters Autopilot et Standard, mettez à jour le cluster à l'aide de l'option --enable-fqdn-network-policy:

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

    Remplacez CLUSTER_NAME par le nom de votre cluster.

  2. Pour les clusters standards uniquement, redémarrez le DaemonSet anetd de GKE Dataplane V2:

    kubectl rollout restart ds -n kube-system anetd

Créer un objet FQDNNetworkPolicy

  1. Enregistrez le manifeste suivant sous le nom 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

    Ce fichier manifeste possède les propriétés suivantes :

    • name: www.google.com : nom de domaine complet. Les adresses IP fournies par le serveur de noms associé à www.google.com sont autorisées. Vous devez spécifier name, pattern, ou les deux.
    • pattern: "*.yourdomain.com" : les adresses IP fournies par les serveurs de noms correspondant à ce modèle sont autorisées. Vous pouvez utiliser les expressions régulières suivantes pour la clé de modèle : ^([a-zA-Z0-9*]([-a-zA-Z0-9_*]*[a-zA-Z0-9*])*\.?)*$. Les critères de correspondance s'ajoutent les uns aux autres. Vous pouvez utiliser plusieurs champs pattern. Vous devez spécifier name, pattern, ou les deux.
    • protocol: "TCP" et port: 443 : spécifient un protocole et un port. Si un pod tente d'établir une connexion à des adresses IP à l'aide de cette combinaison de protocole et de port, la résolution de noms fonctionne, mais le plan de données bloque la connexion sortante. Ce champ est facultatif.

  2. Vérifiez que la règle de réseau sélectionne vos charges de travail :

    kubectl describe fqdnnp

    Le résultat ressemble à ce qui suit :

    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>

Supprimer un objet FQDNNetworkPolicy

Vous pouvez supprimer un FQDNNetworkPolicy à l'aide de la commande kubectl delete fqdnnp :

kubectl delete fqdnnp FQDN_POLICY_NAME

Remplacez FQDN_POLICY_NAME par le nom de votre FQDNNetworkPolicy.

GKE supprime les règles de l'application des règles, mais les connexions existantes restent actives jusqu'à leur fermeture, conformément aux consignes du protocole standard conntrack.

Fonctionnement des règles FQDN

Les objets FQDNNetworkPolicies sont des règles de sortie uniquement qui contrôlent les points de terminaison vers lesquels les pods sélectionnés peuvent envoyer du trafic. Comme pour l'objet NetworkPolicy de Kubernetes, un objet FQDNNetworkPolicy qui sélectionne une charge de travail crée une règle de refus implicite pour les points de terminaison qui ne sont pas spécifiés comme destinations de sortie autorisées. FQDNNetworkPolicies peut être utilisé avec les objets Kubernetes NetworkPolicies, comme décrit dans FQDNNetworkPolicy et NetworkPolicy.

Les règles FQDNNetworkPolicies sont appliquées au niveau de l'adresse IP et du port. Elles ne sont pas appliquées à l'aide d'informations de protocole de couche 7 (par exemple, Request-URI dans une requête HTTP). Les noms de domaine spécifiés sont convertis en adresses IP à l'aide des informations DNS données par le fournisseur DNS du cluster GKE.

Requêtes DNS

Un paramètre FQDNNetworkPolicy actif qui sélectionne les charges de travail n'affecte pas leur capacité à envoyer des requêtes DNS. Les commandes telles que nslookup ou dig fonctionnent sur n'importe quel domaine sans être affectées par la règle. Cependant, les requêtes ultérieures adressées aux domaines de sauvegarde d'adresse IP qui ne figurent pas dans la liste d'autorisation seront abandonnées.

Par exemple, si une règle FQDNNetworkPolicy autorise la sortie vers www.github.com, les requêtes DNS pour tous les domaines sont autorisées, mais le trafic envoyé à une adresse IP utilisant twitter.com est supprimé.

Expiration de TTL

FQDNNetworkPolicy respecte le TTL fourni par un enregistrement DNS. Si un pod tente de contacter une adresse IP arrivée à expiration une fois que le TTL de l'enregistrement DNS est écoulé, les nouvelles connexions sont refusées. Les connexions de longue durée dont la durée dépasse le TTL de l'enregistrement DNS ne devraient pas subir de perturbation de trafic tant que conntrack considère que la connexion est toujours active.

FQDNNetworkPolicy et NetworkPolicy

Lorsqu'une FQDNNetworkPolicy et une NetworkPolicy s'appliquent au même pod, c'est-à-dire que les libellés du pod correspondent à ceux configurés dans les règles, le trafic de sortie est autorisé tant qu'il correspond à l'une des règles. Il n'existe aucune hiérarchie entre l'objet NetworkPolicies de sortie spécifiant des adresses IP ou des sélecteurs de libellés et les objets FQDNNetworkPolicies.

Points de terminaison à adresse IP partagée (équilibreurs de charge, CDN, passerelle VPN, etc.)

De nombreux domaines ne possèdent pas d'adresses IP dédiées sous-jacentes, mais sont exposés à l'aide d'adresses IP partagées. Cela est particulièrement courant lorsque l'application est diffusée par un équilibreur de charge ou un CDN. Par exemple, les API Google Cloud (compute.googleapis.com, container.googleapis.com, etc.) ne possèdent pas d'adresses IP uniques pour chaque API. Au lieu de cela, toutes les API sont exposées à l'aide d'une plage partagée.

Lors de la configuration de FQDNNetworkPolicies, il est important de déterminer si les domaines autorisés utilisent des adresses IP dédiées ou partagées. Étant donné que les règles FQDNNetworkPolicies sont appliqués au niveau de l'adresse IP et du port, elles ne peuvent pas distinguer plusieurs domaines diffusés par la même adresse IP. Autoriser l'accès à un domaine reposant sur une adresse IP partagée permet à votre pod de communiquer avec tous les autres domaines desservis par cette adresse IP. Par exemple, le fait d'autoriser le trafic vers compute.googleapis.com permettra également au pod de communiquer avec d'autres API Google Cloud.

Résolution d'enregistrements CNAME

Si l'objet FQDN du FQDNNetworkPolicy inclut un domaine qui possède des CNAME dans l'enregistrement DNS, vous devez configurer votre FQDNNetworkPolicy avec tous les noms de domaine que votre pod peut interroger directement, y compris tous les alias potentiels, afin de garantir un comportement fiable de FQDNNetworkPolicy.

Si votre pod interroge example.com, alors vous devez écrire example.com dans la règle. Même si vous récupérez une chaîne d'alias provenant de vos serveurs DNS en amont (par exemple, de example.com à example.cdn.com vers 1.2.3.4), la règle de réseau FQDN autorise toujours votre trafic.

Problèmes connus

Cette section répertorie tous les problèmes connus liés aux noms de domaine complets (FQDN).

Si vous spécifiez protocol: ALL, la règle est ignorée.

Ce problème connu a été résolu pour les versions 1.27.10-gke.1055000 et 1.28.3-gke.1055000 et ultérieures de GKE

Si vous créez un FQDNNetworkPolicy qui spécifie protocol: ALL dans la section ports, GKE n'applique pas la règle. Ce problème se produit en raison d'un problème lors de l'analyse de la règle. La spécification de TCP ou UDP n'entraîne pas ce problème.

Pour contourner ce problème, si vous ne spécifiez pas de protocol dans l'entrée ports, la règle correspond à tous les protocoles par défaut. La suppression de protocol: ALL contourne le problème d'analyse et GKE applique FQDNNetworkPolicy.

Dans les versions 1.27.10-gke.1055000 et 1.28.3-gke.1055000 et ultérieures de GKE, les règles contenant protocol: ALL sont analysées et appliquées correctement.

La journalisation NetworkPolicy génère des journaux incorrects ou ne génère pas certains journaux

Ce problème connu a été résolu pour les versions 1.27.10-gke.1055000 et 1.28.2-gke.1157000 et ultérieures de GKE

Si votre cluster utilise la journalisation des règles de réseau et les règles de réseau FQDN, il existe un bug qui peut entraîner des entrées de journal manquantes ou incorrectes.

Lorsque vous utilisez la journalisation des règles de réseau sans délégation, les journaux des règles pour les connexions DNS qui quittent une charge de travail indiquent à tort que le trafic a été supprimé. Le trafic était bien autorisé (conformément à la règle FQDNNetworkPolicy), mais les journaux sont incorrects.

Lorsque vous utilisez la journalisation des règles de réseau avec délégation, il manque certains journaux de règles. Le trafic à proprement parler n'est pas affecté.

Ce bug a été corrigé dans les versions 1.27.10-gke.105500 et 1.28.2-gke.1157000 et ultérieures de GKE. Les connexions DNS sont désormais consignées correctement comme étant autorisées ("ALLOWED"), lorsque le trafic est régi par une règle NetworkPolicy ou FQDNNetworkPolicy.

Étapes suivantes