Utiliser la fonctionnalité de journalisation des règles de réseau

Cette page explique comment utiliser la journalisation des règles de réseau pour Google Kubernetes Engine (GKE). Les règles de réseau Kubernetes spécifient le trafic réseau que les pods sont autorisés à envoyer et à recevoir. La journalisation des règles de réseau vous permet de créer un enregistrement lorsqu'une connexion est autorisée ou refusée par une règle de réseau. La journalisation des règles de réseau peut vous aider à résoudre les problèmes liés aux règles de réseau.

Aperçu

Grâce à la journalisation des règles de réseau, vous pouvez :

• Vérifier que vos règles de réseau fonctionnent comme prévu.
• Identifier les pods de votre cluster qui communiquent avec Internet.
• Identifier les espaces de noms qui communiquent entre eux.
• Reconnaître une attaque par déni de service.

Les journaux des règles de réseau sont importés dans Cloud Logging pour le stockage, la recherche, l'analyse et les alertes si Cloud Logging est activé. Cloud Logging est activé par défaut dans les nouveaux clusters. Pour en savoir plus, consultez la page Configurer la journalisation et la surveillance pour GKE.

Conditions requises

• La journalisation des règles de réseau n'est disponible que pour les clusters qui utilisent GKE Dataplane V2.
• La journalisation des règles de réseau nécessite Google Cloud CLI 303.0.0 ou une version ultérieure.
• La journalisation des règles de réseau n'est pas compatible avec les pools de nœuds Windows Server.

Tarifs

• Aucuns frais de génération de journaux ne sont facturés pour la journalisation des règles de réseau.

• Si vous stockez vos journaux dans Cloud Logging, les tarifs standards de Cloud Logging s'appliquent.

• Les journaux peuvent également être exportés vers Cloud Pub/Sub, Cloud Storage ou BigQuery. Des frais liés à Pub/Sub, Cloud Storage ou BigQuery peuvent s'appliquer. Pour en savoir plus, consultez la page Présentation du routage et du stockage.

Configurer la journalisation des règles de réseau

Pour configurer les paramètres de journalisation des règles de réseau, modifiez l'objet NetworkLogging dans votre cluster. GKE crée automatiquement un objet NetworkLogging nommé default dans les nouveaux clusters Dataplane V2. Il ne peut y avoir qu'un seul objet NetworkLogging par cluster et il ne peut pas être renommé.

Vous pouvez configurer la journalisation des connexions autorisées et celle des connexions refusées séparément. Vous pouvez également activer de manière sélective la journalisation pour certaines règles de réseau. Voici un exemple de spécification NetworkLogging, les paramètres étant spécifiés pour enregistrer toutes les connexions autorisées et refusées :

kind: NetworkLogging
apiVersion: networking.gke.io/v1alpha1
metadata:
  name: default
spec:
  cluster:
    allow:
      log: true
      delegate: false
    deny:
      log: true
      delegate: false

Modifiez votre configuration à l'aide de kubectl :

kubectl edit networklogging default

Spécification NetworkLogging

La spécification d'objet NetworkLogging est au format YAML. Ce format est décrit dans le tableau suivant :

Accéder aux journaux des règles de réseau

Les journaux des règles de réseau sont automatiquement importés dans Cloud Logging. Vous pouvez accéder aux journaux via l'explorateur de journaux ou à l'aide de Google Cloud CLI. Vous pouvez également acheminer les journaux vers un récepteur.

gcloud logging read --project "PROJECT_NAME" 'resource.type="k8s_node"
    resource.labels.location="CLUSTER_LOCATION"
    resource.labels.cluster_name="CLUSTER_NAME"
    logName="projects/PROJECT_NAME/logs/policy-action"'

Vous pouvez ajouter des conditions supplémentaires pour filtrer les résultats. Exemple :

• Afficher les journaux sur une période spécifique :

  timestamp>="2020-06-22T06:30:51.128Z"
  timestamp<="2020-06-23T06:30:51.128Z"
  

• Afficher les journaux liés aux connexions refusées :

  jsonPayload.disposition="deny"
  

• Afficher les journaux dans un déploiement nommé "redis" :

  jsonPayload.dest.pod_name=~"redis"
  jsonPayload.dest.pod_namespace="default"
  

• Afficher les journaux des connexions externes au cluster :

  jsonPayload.dest.instance != ""
  

• Afficher les journaux correspondant à une règle de réseau spécifique ("allow-frontend-to-db", dans ce cas) :

  jsonPayload.policies.name="allow-frontend-to-db"
  jsonPayload.policies.namespace="default"
  

Si vous utilisez un cluster standard, vous pouvez également trouver les journaux des règles de réseau générés sur chaque nœud de cluster en local à l'emplacement /var/log/network/policy_action.log*. Un fichier journal numéroté est créé lorsque le fichier journal actuel atteint 10 Mo. Vous pouvez stocker jusqu'à cinq fichiers journaux précédents.

Format des journaux des règles de réseau

Les enregistrements du journal des règles de réseau sont au format JSON. Ce format est décrit dans le tableau suivant :

Définition de la connexion

Pour les protocoles orientés connexion tels que TCP, un journal est créé pour chaque connexion autorisée ou refusée. Pour les protocoles tels que UDP et ICMP, qui ne sont pas orientés connexion, les paquets sont regroupés en connexions basées sur une fenêtre de temps.

Journaux d'une règle pour les connexions refusées

Les enregistrements du journal des connexions refusées n'incluent pas le champ policies, car l'API des règles de réseau Kubernetes ne dispose pas de règles de refus explicites. Une connexion est refusée si un pod est couvert par une ou plusieurs règles réseau, mais qu'aucune de ces règles n'autorise la connexion. Cela signifie qu'aucune règle n'est seule responsable d'une connexion bloquée.

Agrégation de journaux pour les connexions refusées

Il arrive souvent qu'un client tente à nouveau d'établir une connexion refusée. Pour éviter toute journalisation excessive, les connexions refusées répétées pendant une période de cinq secondes sont regroupées dans un seul message de journal utilisant le champ count.

Les connexions refusées suivantes sont agrégées avec un précédent message de journal si les valeurs src_ip, dest_ip, dest_port, protocol, et direction de la connexion correspondent à la première connexion refusée. Notez que le champ src_port des connexions suivantes ne doit pas nécessairement correspondre, car les nouvelles tentatives de connexion peuvent provenir d'un port différent. Le message de journal agrégé inclut la valeur src_prt de la première connexion refusée au début de la fenêtre d'agrégation.

Exemples d'enregistrements de journal

L'exemple de règle réseau suivant, appelé allow-green et appliqué à test-service, autorise les connexions à test-service depuis un pod nommé client-green. Implicitement, cette règle refuse tout autre trafic entrant vers test-service, y compris à partir du pod client-red.

  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: allow-green
    namespace: default
    annotations:
      policy.network.gke.io/enable-logging: "true"
  spec:
    podSelector:
      matchLabels:
        app: test-service
    ingress:
    - from:
      - podSelector:
          matchLabels:
            app: client-green
    policyTypes:
    - Ingress

Le schéma suivant montre l'effet de la règle allow-green sur deux connexions à test-service. La règle allow-green autorise la connexion depuis client-green. Comme aucune règle ne permet d'établir la connexion depuis client-red, la connexion est refusée.

L'entrée de journal de la connexion autorisée depuis client-green ressemble à ce qui suit :

{
   "connection":{
      "src_ip":"10.84.0.252",
      "dest_ip":"10.84.0.165",
      "src_port":52648,
      "dest_port":8080,
      "protocol":"tcp",
      "direction":"ingress"
   },
   "disposition":"allow",
   "policies":[
      {
         "name":"allow-green",
         "namespace":"default"
      }
   ],
   "src":{
      "pod_name":"client-green-7b78d7c957-68mv4",
      "pod_namespace":"default",
      "namespace":"default",
      "workload_name":"client-green-7b78d7c957",
      "workload_kind":"ReplicaSet"
   },
   "dest":{
      "pod_name":"test-service-745c798fc9-sfd9h",
      "pod_namespace":"default",
      "namespace":"default",
      "workload_name":"test-service-745c798fc9",
      "workload_kind":"ReplicaSet"
   },
   "count":1,
   "node_name":"gke-demo-default-pool-5dad52ed-k0h1",
   "timestamp":"2020-06-16T03:10:37.993712906Z"
}

L'entrée de journal de la connexion refusée depuis client-red ressemble à ce qui suit :

{
   "connection":{
      "src_ip":"10.84.0.180",
      "dest_ip":"10.84.0.165",
      "src_port":39610,
      "dest_port":8080,
      "protocol":"tcp",
      "direction":"ingress"
   },
   "disposition":"deny",
   "src":{
      "pod_name":"client-red-5689846f5b-b5ccx",
      "pod_namespace":"default",
      "namespace":"default",
      "workload_name":"client-red-5689846f5b",
      "workload_kind":"ReplicaSet"
   },
   "dest":{
      "pod_name":"test-service-745c798fc9-sfd9h",
      "pod_namespace":"default",
      "namespace":"default",
      "workload_name":"test-service-745c798fc9",
      "workload_kind":"ReplicaSet"
   },
   "count":3,
   "node_name":"gke-demo-default-pool-5dad52ed-k0h1",
   "timestamp":"2020-06-15T22:38:32.189649531Z"
}

Notez que le journal des connexions refusées n'inclut pas le champ policies. Cette procédure est décrite dans la section précédente, Journaux de règle pour les connexions refusées.

Le journal des connexions refusées comprend un champ count permettant d'agréger les connexions refusées.

Résoudre les problèmes liés aux journaux des règles de réseau

1. Recherchez les événements associés à des erreurs dans l'objet NetworkLogging :

   kubectl describe networklogging default
   

   Si la configuration de journalisation n'est pas valide, elle ne sera pas appliquée et une erreur sera signalée dans la section des événements :

   Name:         default
   Namespace:
   Labels:       addonmanager.kubernetes.io/mode=EnsureExists
   Annotations:  API Version:  networking.gke.io/v1alpha1
   Kind:         NetworkLogging
   Metadata:
     Creation Timestamp:  2020-06-20T05:54:08Z
     Generation:          8
     Resource Version:    187864
     Self Link:           /apis/networking.gke.io/v1alpha1/networkloggings/default
     UID:                 0f1ddd6e-4193-4295-9172-baa6a52aa6e6
   Spec:
     Cluster:
       Allow:
         Delegate:  true
         Log:       false
       Deny:
         Delegate:  false
         Log:       false
   Events:
     Type     Reason                 Age                From                                                               Message
     ----     ------                 ----               ----                                                               -------
     Warning  InvalidNetworkLogging  16s (x3 over 11h)  network-logging-controller, gke-anthos-default-pool-cee49209-0t09  cluster allow log action is invalid: delegate cannot be true when log is false
     Warning  InvalidNetworkLogging  16s (x3 over 11h)  network-logging-controller, gke-anthos-default-pool-cee49209-80fx  cluster allow log action is invalid: delegate cannot be true when log is false
   

2. Pour limiter l'utilisation du processeur par la journalisation, un nœud peut consigner jusqu'à 500 connexions par seconde avant de commencer à supprimer des journaux. Les règles de réseau sur le nœud sont toujours appliquées. Vous pouvez vérifier s'il existe des journaux de stratégie supprimés en vérifiant si les compteurs d'erreurs sont incrémentés :

   kubectl exec ANETD_POD_NAME -n kube-system -- curl -s http://localhost:9990/metrics |grep policy_logging
   

   Remplacez ANETD_POD_NAME par le nom d'un pod anetd. Vérifiez chaque nœud. anetd est le contrôleur réseau pour Dataplane V2.

Les journaux sans nom apparaissent pour les pods utilisant des règles de refus par défaut

Les vérifications d'activité, d'aptitude et de démarrage exigent que le pod accepte les connexions d'entrée associées aux vérifications provenant de kubelet. Pour garantir le bon fonctionnement de ces vérifications, GKE autorise automatiquement le trafic de vérification vers le pod sélectionné, tel que configuré pour le podet indifféremment des règles de réseau appliquées au pod. Vous ne pouvez pas modifier ce comportement.

Les journaux des connexions de vérification sont semblables à ceux-ci :

{
   "connection":{
      "src_ip":"10.88.1.1",
      "dest_ip":"10.88.1.4",
      "src_port":35848,
      "dest_port":15021,
      "protocol":"tcp",
      "direction":"ingress"
   },
   "disposition":"allow",
   "src":{
      "instance":"10.88.1.1"
   },
   "dest":{
      "pod_name":"testpod-745c798fc9-sfd9h",
      "pod_namespace":"default",
      "namespace":"default",
      "workload_name":"testpod-745c798fc9",
      "workload_kind":"ReplicaSet"
   },
   "count":1,
   "policies": [
     {
       "name":""
     }
    ],
   "node_name":"gke-demo-default-pool-5dad52ed-k0h1",
   "timestamp":"2021-04-01T12:42:32.1898720941Z"
}

Le journal possède les caractéristiques suivantes :

• La valeur policies.name est vide, car aucune règle de réseau associée n'autorise la connexion.
• La valeur de connection.src_ip ne correspond à aucun pod ni nœud.

Étape suivante

• Apprenez à afficher et analyser des journaux avec Cloud Logging.
• Mettez en œuvre des approches courantes pour restreindre le trafic à l'aide de règles de réseau.

• Découvrez comment afficher la connectivité de la charge de travail avec GKE Dataplane V2.