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.

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:

CampoTipoDescrição
cluster.allowstruct Configurações para registrar conexões autorizadas.
CampoTipoDescriçã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.
CampoTipoDescriçã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:

CampoTipoDescrição
connectionstruct Informações sobre conexão:
CampoTipoDescrição
src_ipstringEndereço IP de origem da conexão.
src_portintPorta de origem da conexão.
dest_ipstringEndereço IP de destino da conexão.
dest_portintPorta de destino da conexão.
protocolstringProtocolo da conexão, que pode ser tcp, udp ou icmp.
directionstringDireção da conexão, que pode ser ingress ou egress.
srcstruct Informações de endpoint da origem:
CampoTipoDescrição
pod_namestringNome do pod, se a origem for um pod.
pod_namespace (deprecated)stringNamespace do pod, se a origem for um pod. O uso de pod_namespace foi suspenso. Use namespace.
namespacestringNamespace do pod, se a origem for um pod.
workload_namestringNome da carga de trabalho, se a carga de trabalho de origem estiver disponível.
workload_kindstringTipo de carga de trabalho, se a carga de trabalho de origem estiver disponível.
instancestringEndereço IP da origem, se a origem não for um pod.
deststruct Informações de endpoint do destino:
CampoTipoDescrição
pod_namestringNome do pod, se o destino for um pod.
pod_namespace (deprecated)stringNamespace do pod, se o destino for um pod. O uso de pod_namespace foi suspenso. Use namespace.
namespacestringNamespace do pod, se o destino for um pod.
workload_namestringNome da carga de trabalho, se ela estiver disponível.
workload_kindstringTipo de carga de trabalho, se a carga de trabalho de destino estiver disponível.
instancestringEndereço IP da origem, se o destino não for um pod.
dispositionstringDisposição da conexão, que pode ser allow ou deny.
policieslist 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.

CampoTipoDescrição
namestringNome da política de rede correspondente.
namespacestringNamespace da política de rede correspondente.
countintUsado para agregação de registros de consultas negadas. O valor é sempre 1 para a conexão autorizada.
node_namestringO nó que executa o pod que gerou essa mensagem de registro.
timestampstringQuando ocorreu a tentativa de conexão.

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.

image

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