Como usar a geração de registros de política de rede


Nesta página, explicamos como usar o registro de políticas de rede do Google Kubernetes Engine (GKE).

Visão geral

As políticas de rede 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. 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 instalar o Cloud Operations para suporte do GKE para mais informações.

Requisitos

  • A geração de registros de políticas de rede só está disponível para clusters que usam Dataplane V2.
  • O registro de políticas de rede requer o SDK do Cloud 303.0.0 ou superior.

Preços

  • Não há cobranças sobre a geração de registros para registros de política de rede na versão Beta.
  • Se você armazenar seus registros no Cloud Logging, serão aplicadas cobranças padrão do Cloud Logging.
  • Eles podem ser exportados para o Pub/Sub, o Cloud Storage ou o BigQuery, que estão sujeitos a cobranças. Para mais informações sobre como exportar registros, consulte Visão geral da exportação de registros.

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 os registros

Os registros da política de rede gerados em cada nó do cluster estão disponíveis localmente 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.

Os registros da política de rede são enviados automaticamente para o Cloud Logging. É possível acessar os registros com o Explorador de registros ou com a ferramenta de linha de comando gcloud. Também é possível exportar registros do Cloud Logging para o coletor de sua escolha.

gcloud

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: a zona em que seu cluster está;
  • CLUSTER_NAME: o nome do cluster.

Cloud Logging

  1. Acesse o menu de navegação do Google Cloud e selecione Logging > Explorador de registros:
    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: a zona em que seu cluster está;
    • 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.

É possível adicionar outras condições para filtrar os resultados. Por 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"
    

Formato do registro

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_namespacestringNamespace do pod, se a origem for um pod.
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_namespacestringNamespace do pod, se o destino for um pod.
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.

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"
   },
   "dest":{
      "pod_name":"test-service-745c798fc9-sfd9h",
      "pod_namespace":"default"
   },
   "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"
   },
   "dest":{
      "pod_name":"test-service-745c798fc9-sfd9h",
      "pod_namespace":"default"
   },
   "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

  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, ela 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. Um nó pode registrar até 500 conexões por segundo. Verifique se há registros de política descartados conferindo se algum contador de erros está incrementando:

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

    Substitua ANETD_XYZ pelo nome de um pod do Anetd. Verifique cada nó. anetd é o controlador de rede do Dataplane V2.

A seguir