Use o registo da política de rede

Esta página explica como usar o registo de políticas de rede para o Google Kubernetes Engine (GKE). As políticas de rede do Kubernetes especificam o tráfego de rede que os pods podem enviar e receber. O registo de políticas de rede permite-lhe registar quando uma ligação é permitida ou recusada por uma política de rede. O registo de políticas de rede pode ajudar a resolver problemas com políticas de rede.

Vista geral

Através do registo da política da rede, pode:

• Verifique se as políticas de rede estão a funcionar conforme esperado.
• Compreenda que Pods no seu cluster estão a comunicar com a Internet.
• Compreender que namespaces estão a comunicar entre si.
• Reconheça um ataque de negação de serviço.

Os registos de políticas de rede são carregados para o Cloud Logging para armazenamento, pesquisa, análise e alertas se o Cloud Logging estiver ativado. O Cloud Logging está ativado por predefinição em novos clusters. Consulte o artigo Configurar o registo e a monitorização para o GKE para mais informações.

Requisitos

• O registo da política de rede só está disponível para clusters que usam o GKE Dataplane V2.
• O registo de políticas de rede requer a CLI Google Cloud 303.0.0 ou superior.
• O registo da política de rede não é suportado com pools de nós do Windows Server.

Preços

• Não existem cobranças de geração de registos para o registo de políticas de rede.

• Os registos podem ser encaminhados para o Pub/Sub, o Cloud Storage ou o BigQuery. Podem aplicar-se encargos do Pub/Sub, Cloud Storage ou BigQuery. Para mais informações, consulte o artigo Vista geral do encaminhamento e armazenamento.

Configurar registo de políticas de rede

Pode configurar as definições de registo da política de rede editando o objeto NetworkLogging no cluster. O GKE cria automaticamente um objeto NetworkLogging denominado default em novos clusters do Dataplane V2. Só pode existir um objeto NetworkLogging por cluster e não é possível mudar-lhe o nome.

Pode configurar o registo de ligações permitidas e o registo de ligações negadas separadamente. Também pode ativar seletivamente o registo para algumas políticas de rede. Segue-se um exemplo da especificação NetworkLogging, com definições especificadas para registar todas as ligações permitidas e recusadas:

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

Use kubectl para editar a configuração:

kubectl edit networklogging default

Especificação NetworkLogging

A especificação do objeto NetworkLogging está num formato YAML. Este formato é descrito na tabela seguinte:

Aceder aos registos da política de rede

Os registos de políticas de rede são carregados automaticamente para o Cloud Logging. Pode aceder aos registos através do Explorador de registos ou com a CLI do Google Cloud. Também pode encaminhar registos para um destino.

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

Pode adicionar mais condições para filtrar os resultados. Por exemplo:

• Mostrar registos num determinado período:

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

• Mostrar registos de ligações recusadas:

  jsonPayload.disposition="deny"
  

• Mostrar registos de uma implementação denominada "redis":

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

• Mostrar registos de ligações externas ao cluster:

  jsonPayload.dest.instance != ""
  

• Mostrar registos que correspondam a uma determinada política de rede, neste caso, "allow-frontend-to-db":

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

Se usar um cluster padrão, também pode encontrar os registos da política de rede gerados em cada nó do cluster localmente em /var/log/network/policy_action.log*. É criado um novo ficheiro de registo numerado quando o ficheiro de registo atual atinge 10 MB. São armazenados até cinco ficheiros de registo anteriores.

Formato do registo da política de rede

Os registos de registo de políticas de rede estão num formato JSON. Este formato é descrito na tabela seguinte:

Definição de ligação

Para protocolos orientados para a ligação, como o TCP, é criado um registo para cada ligação permitida ou recusada. Para protocolos como UDP e ICMP que não são orientados para a ligação, os pacotes são agrupados em ligações baseadas em janelas de tempo.

Registos de políticas para ligações recusadas

Os registos dos registos para ligações recusadas não incluem o campo policies porque a API de política de rede do Kubernetes não tem políticas de recusa explícitas. Uma ligação é recusada se um Pod estiver abrangido por uma ou mais políticas de rede, mas nenhuma das políticas permitir a ligação. Isto significa que nenhuma política é individualmente responsável por uma ligação bloqueada.

Agregação de registos para ligações recusadas

É comum um cliente tentar novamente uma ligação que foi recusada. Para evitar o registo excessivo, as ligações recusadas repetidas num período de cinco segundos são agregadas numa única mensagem de registo através do campo count.

As ligações recusadas subsequentes são agregadas com uma mensagem de registo anterior se o src_ip, dest_ip, dest_port, protocol,e o direction da ligação corresponderem à primeira ligação recusada. Tenha em atenção que a src_port das ligações subsequentes não tem de corresponder, uma vez que as ligações repetidas podem vir de uma porta diferente. A mensagem de registo agregada inclui o src_prt da primeira ligação recusada no início do período de agregação.

Exemplos de registos de logs

A seguinte política de rede de exemplo denominada allow-green aplicada a test-service permite ligações a test-service a partir de um pod denominado client-green. Implicitamente, esta política nega todo o outro tráfego de entrada para test-service, incluindo a partir do 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

Este diagrama mostra o efeito da política allow-green em duas ligações a test-service. A política allow-green permite a ligação a partir de client-green. Uma vez que nenhuma política permite a ligação a partir de client-red, a ligação é recusada.

O registo da ligação permitida de client-green tem o seguinte aspeto:

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

O registo da ligação recusada de client-red tem o seguinte aspeto:

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

Tenha em atenção que o registo de ligação recusada não inclui o campo policies. Isto é descrito na secção anterior, Registos de políticas para ligações recusadas.

O registo de ligações recusadas inclui um campo count para agregar ligações recusadas.

Resolução de problemas com registos de políticas de rede

1. Verifique se existem eventos de erros no objeto NetworkLogging:

   kubectl describe networklogging default
   

   Se a configuração de registo for inválida, a configuração não é aplicada e é comunicado um erro na secção de eventos:

   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. Para limitar a utilização da CPU gasta no registo, um nó pode registar até 500 ligações por segundo antes de começar a rejeitar registos. As políticas de rede no nó continuam a ser aplicadas. Pode verificar se existem registos de políticas rejeitados verificando se algum contador de erros está a aumentar:

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

   Substitua ANETD_POD_NAME pelo nome de um anetd Pod. Verifique cada nó. O anetd é o controlador de rede para o Dataplane V2.

Os registos sem nome são apresentados para pods com políticas de recusa predefinidas

As sondas de atividade, prontidão e arranque requerem que o pod aceite ligações de entrada feitas pelas sondas do kubelet. Para garantir que estas sondas funcionam corretamente, o GKE permite automaticamente o tráfego de sondas para o pod selecionado, conforme configurado para o pod, independentemente das políticas de rede aplicadas ao pod. Não pode alterar este comportamento.

Os registos das ligações de sondagem são semelhantes aos seguintes:

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

O registo tem as seguintes características:

• O valor de policies.name está vazio porque não existe uma política de rede associada para permitir a ligação.
• O valor de connection.src_ip não corresponde a nenhum pod ou nó.

O que se segue?

• Saiba como ver e analisar registos com o Cloud Logging.
• Implemente abordagens comuns para restringir o tráfego através de políticas de rede.