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:
Campo | Tipo | Descrição | |||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
cluster.allow | struct |
Configurações para registrar conexões autorizadas.
|
|||||||||
cluster.deny |
struct |
Configurações para registrar conexões negadas.
|
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
Acesse a página do Explorador de registros no console do Google Cloud:
Clique em Criador de consultas.
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:
|
|||||||||||||||||||||
src | struct |
Informações de endpoint da origem:
|
|||||||||||||||||||||
dest | struct |
Informações de endpoint do destino:
|
|||||||||||||||||||||
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.
|
|||||||||||||||||||||
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. |
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
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
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.