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

Autopilot Padrão

---

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

Observação: se você usar políticas de rede para restringir o tráfego no Anthos Service Mesh, implante suas políticas de rede antes de ativar o Anthos Service Mesh em um namespace. Caso contrário, as conexões de longa duração entre os pods na malha podem já ter sido estabelecidas e a ativação de novas políticas de rede não encerrará as conexões atuais.

Especificação do NetworkLogging

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

Campo	Tipo	Descrição
cluster.allow	struct	Configurações para registrar conexões autorizadas. Campo Tipo Descrição log bool Se definidas como true, as conexões autorizadas no cluster serão registradas. Caso contrário, não serão registradas. As políticas de rede que selecionam o pod e têm uma regra que correspondem à conexão são listadas na mensagem de registro. delegate bool Se false, todas as conexões autorizadas serão registradas. Se várias políticas de rede permitirem uma conexão, todas as políticas correspondentes serão listadas na mensagem de registro. Se true, as conexões autorizadas serão registradas somente se permitidas por uma política de rede com a anotação de registro policy.network.gke.io/enable-logging: "true". Se várias políticas de rede permitirem uma conexão, todas as políticas correspondentes com a anotação enable-logging serão listadas na mensagem de registro. Um erro de configuração ocorrerá se você definir spec.cluster.allow.delegate como true e spec.cluster.allow.log como false.
cluster.deny	struct	Configurações para registrar conexões negadas. Campo Tipo Descrição log bool Se definidas como true, as conexões negadas no cluster serão registradas. Caso contrário, não serão registradas. delegate bool Se false, todas as conexões negadas serão registradas. Se true, as conexões negadas serão registradas somente se o pod em que a conexão foi negada estiver em um namespace com a anotação policy.network.gke.io/enable-deny-logging: "true". Um erro de configuração ocorrerá se você definir spec.cluster.deny.delegate como true e spec.cluster.deny.log como false.

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.

Cloud Logging

1. Acesse a página do Explorador de registros no console do Google Cloud:

   Acessar o Explorador de registros

2. Clique em Criador de consultas.

3. Use a seguinte consulta para encontrar todos os registros de políticas de rede:

   resource.type="k8s_node"
   resource.labels.location="CLUSTER_LOCATION"
   resource.labels.cluster_name="CLUSTER_NAME"
   logName="projects/PROJECT_NAME/logs/policy-action"
   

   Substitua:

   • CLUSTER_LOCATION: o local do Compute Engine do cluster.
   • CLUSTER_NAME: o nome do cluster.
   • PROJECT_NAME: o nome do seu projeto do Google Cloud;

Consulte Como usar o Explorador de registros para saber como usá-lo.

Também é possível criar uma consulta usando o Criador de consultas. Para criar uma consulta para registros de política de rede, selecione policy-action na lista suspensa Nome do registro. Se não houver registros disponíveis, a policy-action não aparecerá na lista suspensa.

gcloud

Encontre todos os registros de políticas de rede:

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

Substitua:

• PROJECT_NAME: o nome do seu projeto do Google Cloud;
• CLUSTER_LOCATION: o local do Compute Engine do cluster.
• CLUSTER_NAME: o nome do cluster.

É 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:

Campo	Tipo	Descrição
connection	struct	Informações sobre conexão: Campo Tipo Descrição src_ip string Endereço IP de origem da conexão. src_port int Porta de origem da conexão. dest_ip string Endereço IP de destino da conexão. dest_port int Porta de destino da conexão. protocol string Protocolo da conexão, que pode ser tcp, udp ou icmp. direction string Direção da conexão, que pode ser ingress ou egress.
src	struct	Informações de endpoint da origem: Campo Tipo Descrição pod_name string Nome do pod, se a origem for um pod. pod_namespace (deprecated) string Namespace do pod, se a origem for um pod. O uso de pod_namespace foi suspenso. Use namespace. namespace string Namespace do pod, se a origem for um pod. workload_name string Nome da carga de trabalho, se a carga de trabalho de origem estiver disponível. workload_kind string Tipo de carga de trabalho, se a carga de trabalho de origem estiver disponível. instance string Endereço IP da origem, se a origem não for um pod.
dest	struct	Informações de endpoint do destino: Campo Tipo Descrição pod_name string Nome do pod, se o destino for um pod. pod_namespace (deprecated) string Namespace do pod, se o destino for um pod. O uso de pod_namespace foi suspenso. Use namespace. namespace string Namespace do pod, se o destino for um pod. workload_name string Nome da carga de trabalho, se ela estiver disponível. workload_kind string Tipo de carga de trabalho, se a carga de trabalho de destino estiver disponível. instance string Endereço IP da origem, se o destino não for um pod.
disposition	string	Disposição da conexão, que pode ser allow ou deny.
policies	list of structs	Políticas correspondentes para as conexões autorizadas da visualização do pod aplicado. Para conexão de entrada, o pod aplicado é o pod de destino. Para a conexão de saída, o pod aplicado é o pod de origem. Várias políticas são registradas quando uma conexão corresponde a todas elas. Este campo é incluído apenas em registros de conexões autorizadas. Campo Tipo Descrição name string Nome da política de rede correspondente. namespace string Namespace da política de rede correspondente.
count	int	Usado para agregação de registros de consultas negadas. O valor é sempre 1 para a conexão autorizada.
node_name	string	O nó que executa o pod que gerou essa mensagem de registro.
timestamp	string	Quando ocorreu a tentativa de conexão.

Observação: namespace, workload_name e workload_kind estão disponíveis nas seguintes versões:

• 1.20.10-gke.2200 a 1.21
• 1.21.4-gke.2300 a 1.22
• 1.22.1-gke.1700 e superior

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.