Usar a geração de registros da política de rede

Nesta página, explicamos como usar o registro de políticas de rede do Google Kubernetes Engine (GKE). As políticas de rede do Kubernetes especificam o tráfego de rede que os pods podem enviar e receber. A geração de registros de políticas de rede permite registrar quando uma conexão é autorizada ou negada por uma política de rede. O registro de políticas de rede pode ajudar a resolver problemas com as políticas de rede.

Visão geral

Com o registro de políticas de rede, é possível:

• verificar se as políticas de rede estão funcionando conforme o esperado;
• saber quais pods no cluster estão se comunicando com a Internet;
• entender quais namespaces estão se comunicando;
• reconhecer um ataque de negação de serviço.

Os registros de política de rede são enviados ao Cloud Logging para armazenamento, pesquisa, análise e alerta se o Cloud Logging estiver ativado. O Cloud Logging é ativado por padrão em novos clusters. Consulte Como configurar a geração de registros e o monitoramento do GKE para saber mais.

Requisitos

• A geração de registros de políticas de rede só está disponível para clusters que usam Dataplane V2 GKE.
• A geração de registros de políticas de rede demanda a Google Cloud CLI versão 303.0.0 ou mais recente.
• A geração de registros de políticas de rede não é compatível com pools de nós do Windows Server.

Preços

• Não há cobrança de geração de registros para a geração de registros de política de rede.

• Se você armazenar seus registros no Cloud Logging, serão aplicadas cobranças padrão do Cloud Logging.

• Os registros podem ser exportados para o Pub/Sub, o Cloud Storage ou o BigQuery. que estão sujeitos a cobranças. Para mais informações, consulte Visão geral de roteamento e armazenamento.

Como configurar a geração de registros da políticas de rede

Para definir as configurações de geração de registros da política de rede, edite o objeto NetworkLogging no cluster. O GKE cria automaticamente um objeto NetworkLogging chamado default em novos clusters do Dataplane V2 . Só pode haver um objeto NetworkLogging por cluster, e ele não pode ser renomeado.

É possível configurar separadamente os registros de conexões autorizadas e negadas. É possível ativar, de forma seletiva, a geração de registros de algumas políticas de rede. Veja a seguir um exemplo da especificação NetworkLogging, com configurações especificadas para registrar todas as conexões autorizadas e negadas:

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 sua configuração:

kubectl edit networklogging default

Especificação do NetworkLogging

A especificação do objeto NetworkLogging está no formato YAML. Esse formato é descrito na tabela a seguir:

Como acessar registros de política de rede

Os registros da política de rede são enviados automaticamente para o Cloud Logging. É possível acessar registros pelo Explorador de registros ou com a Google Cloud CLI. Você também pode encaminhar registros para um coletor.

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

É possível adicionar outras condições para filtrar os resultados. Exemplo:

• Mostrar registros em um determinado período:

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

• Mostrar registros de conexões negadas:

  jsonPayload.disposition="deny"
  

• Mostrar registros de uma implantação chamada "redis":

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

• Mostrar registros de conexões externas do cluster:

  jsonPayload.dest.instance != ""
  

• Mostrar registros que correspondem 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 você usa um cluster padrão, também pode encontrar localmente os registros de política de rede gerados em cada nó do cluster em /var/log/network/policy_action.log*. Um novo arquivo de registros numerado é criado quando o arquivo de registros atual atinge 10 MB. Até cinco arquivos de registros anteriores são armazenados.

Formato de registro da política de rede

Os registros de política de rede estão no formato JSON. Esse formato é descrito na tabela a seguir:

Definição de conexão

Para protocolos orientados por conexão, como TCP, um registro é criado para cada conexão autorizada ou negada. Para protocolos como UDP e ICMP que não são orientados por conexão, os pacotes são agrupados em conexões baseadas em janelas de tempo.

Registros de política para conexões negadas

Os registros de conexões negadas não incluem o campo policies porque a API de política de rede do Kubernetes não tem políticas de negação explícitas. Uma conexão será negada se um pod for abrangido por uma ou mais políticas de rede, mas nenhuma das políticas permitir a conexão. Isso significa que nenhuma política é particularmente responsável por uma conexão bloqueada.

Agregação de registro para conexões negadas

É comum que um cliente tente novamente a conexão recusada. Para evitar a geração de registros em excesso, conexões negadas repetidas dentro de uma janela de cinco segundos são agregadas em uma única mensagem de registro usando o campo count.

As conexões negadas subsequentes são agregadas com uma mensagem de registro anterior se src_ip, dest_ip, dest_port, protocol, e direction da conexão corresponderem à primeira conexão negada. Observe que o src_port de conexões subsequentes não precisa corresponder porque as conexões repetidas podem vir de uma porta diferente. A mensagem de registro agregada inclui o src_prt da primeira conexão negada no início da janela de agregação.

Exemplos de registros

O exemplo de política de rede a seguir, allow-green, aplicado a test-service, permite conexões com test-service de um pod chamado client-green. Essa política nega, de forma implícita, todo o tráfego de entrada para test-service, inclusive 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 conexões com test-service. A política allow-green permite a conexão de client-green. Como nenhuma política permite a conexão de client-red, a conexão é negada.

O registro da conexão autorizada de client-green tem a seguinte aparência:

{
   "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 registro da conexão negada de client-red tem a seguinte aparência:

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

Observe que o registro de conexão negada não inclui o campo policies. Isso é descrito na seção anterior (Registros de política para conexões negadas).

O registro de conexão negada inclui um campo count para agregar conexões negadas.

Solução de problemas com os registros de política de rede

1. Verifique se há eventos de erro no objeto NetworkLogging:

   kubectl describe networklogging default
   

   Se a configuração de geração de registros for inválida, a configuração não terá efeito e um erro será informado na seçã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 na geração de registros, um nó pode registrar até 500 conexões por segundo antes de começar a descartar registros. As políticas de rede no nó ainda estão sendo aplicadas. É possível ver se há registros de política descartados verificando se os contadores de erro estão incrementando:

   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 pod do Anetd. Verifique cada nó. anetd é o controlador de rede do Dataplane V2.

Registros sem nome aparecem para pods com políticas de negação padrão

As sondagens de atividade, prontidão e inicialização exigem que o pod aceite conexões Ingress feitas pelas sondagens do kubelet. Para garantir que essas sondagens funcionem corretamente, o GKE permite automaticamente o tráfego de sondagem para o pod selecionado, conforme configurado para o pod, independentemente de quaisquer políticas de rede aplicadas ao pod. Não é possível alterar esse comportamento.

Os registros das conexõ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 registro tem as seguintes características:

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

A seguir

• Saiba como visualizar e analisar registros com o Cloud Logging.
• Implementar abordagens comuns para restringir o tráfego usando políticas de rede.

• Saiba como ver a conectividade da carga de trabalho com o GKE Dataplane V2.