Utilizzo del logging dei criteri di rete

Questa pagina spiega come utilizzare la registrazione dei criteri di rete per Google Kubernetes Engine (GKE). I criteri di rete di Kubernetes specificano il traffico di rete che i pod sono autorizzati a inviare e ricevere. La registrazione dei criteri di rete consente di registrare quando una connessione viene consentita o negata da un criterio di rete. La registrazione delle policy di rete può aiutarti a risolvere i problemi relativi alle policy di rete.

Panoramica

Utilizzando il logging dei criteri di rete, puoi:

• Verifica che le tue norme di rete funzionino come previsto.
• Capire quali pod nel tuo cluster comunicano con internet.
• Capire quali spazi dei nomi comunicano tra loro.
• Riconoscere un attacco Denial of Service.

I log dei criteri di rete vengono caricati in Cloud Logging per l'archiviazione, la ricerca, l'analisi e la generazione di avvisi se Cloud Logging è abilitato. Cloud Logging è abilitato per impostazione predefinita nei nuovi cluster. Per saperne di più, consulta la sezione Configurazione di logging e monitoraggio per GKE.

Requisiti

• Il logging dei criteri di rete è disponibile solo per i cluster che utilizzano GKE Dataplane V2.
• La registrazione delle policy di rete richiede Google Cloud CLI 303.0.0 o versioni successive.
• La registrazione dei criteri di rete non è supportata con i node pool Windows Server.

Prezzi

• Non sono previsti costi per la generazione di log per la registrazione dei criteri di rete.

• Se archivi i log in Cloud Logging, si applicano i costi standard di Cloud Logging.

• I log possono essere ulteriormente indirizzati a Pub/Sub, Cloud Storage o BigQuery. Potrebbero essere applicati costi per Pub/Sub, Cloud Storage o BigQuery. Per ulteriori informazioni, vedi Panoramica su routing e archiviazione.

Configurazione del logging dei criteri di rete

Configura le impostazioni di logging delle policy di rete modificando l'oggetto NetworkLogging nel cluster. GKE crea automaticamente un oggetto NetworkLogging denominato default nei nuovi cluster Dataplane V2. Può esserci un solo oggetto NetworkLogging per cluster e non può essere rinominato.

Puoi configurare la registrazione delle connessioni consentite e delle connessioni negate separatamente. Puoi anche attivare selettivamente la registrazione per alcuni criteri di rete. Di seguito è riportato un esempio della specifica NetworkLogging, con le impostazioni specificate per registrare tutte le connessioni consentite e negate:

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

Utilizza kubectl per modificare la configurazione:

kubectl edit networklogging default

NetworkLogging spec

La specifica dell'oggetto NetworkLogging è in formato YAML. Questo formato è descritto nella tabella seguente:

Accesso ai log dei criteri di rete

I log delle norme di rete vengono caricati automaticamente in Cloud Logging. Puoi accedere ai log tramite Esplora log o con Google Cloud CLI. Puoi anche instradare i log a un sink.

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"'

Puoi aggiungere altre condizioni per filtrare i risultati. Ad esempio:

• Mostrare i log in un determinato periodo di tempo:

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

• Mostra log per le connessioni rifiutate:

  jsonPayload.disposition="deny"
  

• Mostra i log di un deployment denominato "redis":

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

• Mostra i log per le connessioni esterne al cluster:

  jsonPayload.dest.instance != ""
  

• Mostra i log che corrispondono a un determinato criterio di rete, in questo caso "allow-frontend-to-db":

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

Se utilizzi un cluster Standard, puoi anche trovare i log dei criteri di rete generati su ogni nodo del cluster localmente in /var/log/network/policy_action.log*. Viene creato un nuovo file di log numerato quando il file di log corrente raggiunge i 10 MB. Vengono memorizzati fino a cinque file di log precedenti.

Formato del log dei criteri di rete

I record di log dei criteri di rete sono in formato JSON. Questo formato è descritto nella tabella seguente:

Definizione di connessione

Per i protocolli orientati alla connessione come TCP, viene creato un log per ogni connessione consentita o negata. Per i protocolli come UDP e ICMP che non sono orientati alla connessione, i pacchetti vengono raggruppati in connessioni basate su finestre temporali.

Log dei criteri per le connessioni negate

I record di log per le connessioni negate non includono il campo policies perché l'API Kubernetes Network Policy non dispone di criteri di negazione espliciti. Una connessione viene negata se un pod è coperto da una o più policy di rete, ma nessuna delle policy consente la connessione. Ciò significa che nessuna norma è individualmente responsabile di una connessione bloccata.

Aggregazione dei log per le connessioni rifiutate

È normale che un client riprovi una connessione che è stata negata. Per evitare la registrazione eccessiva, le connessioni rifiutate ripetute in un intervallo di cinque secondi vengono aggregate in un unico messaggio di log utilizzando il campo count.

Le connessioni rifiutate successive vengono aggregate a un messaggio di log precedente se src_ip, dest_ip, dest_port, protocol,e direction della connessione corrispondono alla prima connessione rifiutata. Tieni presente che la src_port delle connessioni successive non deve corrispondere perché i tentativi di connessione potrebbero provenire da una porta diversa. Il messaggio di log aggregato include src_prt della prima connessione negata all'inizio della finestra di aggregazione.

Esempi di record di log

La seguente policy di rete di esempio denominata allow-green applicata a test-service consente le connessioni a test-service da un pod denominato client-green. Implicitamente, questo criterio nega tutto il traffico in entrata a test-service, incluso quello proveniente dal 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

Questo diagramma mostra l'effetto del criterio allow-green su due connessioni a test-service. Il criterio allow-green consente la connessione da client-green. Poiché nessun criterio consente la connessione da client-red, la connessione viene negata.

Il log per la connessione consentita da client-green ha il seguente aspetto:

{
   "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"
}

Il log per la connessione rifiutata da client-red ha il seguente aspetto:

{
   "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"
}

Tieni presente che il log delle connessioni rifiutate non include il campo policies. Questo è descritto nella sezione precedente, Log dei criteri per le connessioni negate.

Il log delle connessioni negate include un campo count per aggregare le connessioni negate.

Risoluzione dei problemi relativi ai log delle norme di rete

1. Controlla la presenza di eventi di errore nell'oggetto NetworkLogging:

   kubectl describe networklogging default
   

   Se la configurazione del logging non è valida, la configurazione non verrà applicata e verrà segnalato un errore nella sezione degli eventi:

   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. Per limitare l'utilizzo della CPU dedicato alla registrazione, un nodo può registrare fino a 500 connessioni al secondo prima di iniziare a eliminare i log. I criteri di rete sul nodo sono ancora applicati. Puoi verificare se sono presenti log delle norme eliminati controllando se i contatori degli errori aumentano:

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

   Sostituisci ANETD_POD_NAME con il nome di un pod anetd. Controlla ogni nodo. anetd è il controller di rete per Dataplane V2.

I log senza nome vengono visualizzati per i pod con policy di rifiuto predefinite

I probe di attività, idoneità e avvio richiedono che il pod accetti le connessioni Ingress effettuate dai probe da kubelet. Per garantire il corretto funzionamento di questi probe, GKE consente automaticamente il traffico del probe al pod selezionato come configurato per il pod, indipendentemente dalle policy di rete applicate al pod. Non puoi modificare questo comportamento.

I log per le connessioni dei probe sono simili ai seguenti:

{
   "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"
}

Il log ha le seguenti caratteristiche:

• Il valore di policies.name è vuoto perché non esiste una policy di rete associata per consentire la connessione.
• Il valore di connection.src_ip non corrisponde ad alcun pod o nodo.

Passaggi successivi

• Scopri come visualizzare e analizzare i log con Cloud Logging.
• Implementa approcci comuni per limitare il traffico utilizzando i criteri di rete.