Esta página foi traduzida pela API Cloud Translation.

Controle o tráfego de saída do pod com políticas de rede FQDN

Autopilot Padrão

Esta página explica como controlar a comunicação de saída entre os pods e os recursos fora do cluster do Google Kubernetes Engine (GKE) através de nomes de domínio totalmente qualificados (FQDN). O recurso personalizado que usa para configurar FQDNs é o recurso FQDNNetworkPolicy.

Antes de começar

Antes de começar, certifique-se de que realizou as seguintes tarefas:

Ative a API Google Kubernetes Engine.

Ative a API Google Kubernetes Engine

Se quiser usar a CLI gcloud para esta tarefa, instale-a e, em seguida, inicialize-a. Se instalou anteriormente a CLI gcloud, execute gcloud components update para obter a versão mais recente.
Nota: para instalações existentes da CLI gcloud, certifique-se de que define a compute/region propriedade. Se usar principalmente clusters zonais, defina o compute/zone. Ao definir uma localização predefinida, pode evitar erros na CLI gcloud, como os seguintes: One of [--zone, --region] must be supplied: Please specify location. Pode ter de especificar a localização em determinados comandos se a localização do seu cluster for diferente da predefinição que definiu.

Requisitos e limitações

Os recursos FQDNNetworkPolicy têm os seguintes requisitos e limitações:

Tem de ter um cluster do GKE a executar uma das seguintes versões:
- 1.26.4-gke.500 ou posterior
- 1.27.1-gke.400 ou posterior
O cluster tem de usar o GKE Dataplane V2.
- Tem de usar um dos fornecedores de DNS no seu cluster do GKE: kube-dns ou Cloud DNS. As implementações personalizadas de kube-dns ou Core DNS não são suportadas.
Versão 462.0.0 ou posterior da CLI gcloud.
Os pools de nós do Windows não são suportados.
O Cloud Service Mesh não é suportado.
Se tiver endereços IP codificados na sua aplicação, use o campo IPBlock do Kubernetes NetworkPolicy em vez de um FQDNNetworkPolicy.
Os resultados devolvidos por servidores de nomes DNS não pertencentes a clusters, como servidores de nomes alternativos em resolv.conf, não são considerados válidos para serem programados na lista de autorizações no plano de dados do GKE.
O número máximo de endereços IP IPv4 e IPv6 que um FQDNNetworkPolicy pode resolver é 50.
Não pode permitir tráfego para um ClusterIP ou um serviço sem cabeça como destino de saída num FQDNNetworkPolicy, porque o GKE traduz o endereço IP virtual (VIP) do serviço para endereços IP de pods de back-end antes de avaliar as regras da política de rede. Em alternativa, use um seletor de nós baseado em etiquetas do Kubernetes NetworkPolicy.
Existe uma quota máxima de 100 endereços IP por nome de anfitrião.
A encriptação transparente entre nós não é suportada com políticas de rede de FQDN.
As políticas de rede FQDN que usam a correspondência de padrões só correspondem a subdomínios no mesmo nível que o caráter universal. Por exemplo, pattern: *.company.com corresponde a api.company.com ou store.company.com, mas não a eu.api.company.com ou company.com.

Ative a política de rede FQDN

Pode ativar a política de rede FQDN num cluster novo ou existente.

Ative a política de rede FQDN num novo cluster

Crie o cluster através da flag --enable-fqdn-network-policy:

gcloud container clusters create CLUSTER_NAME  \
    --enable-fqdn-network-policy

Substitua CLUSTER_NAME pelo nome do seu cluster.

Ative a política de rede FQDN num cluster existente

Para clusters do Autopilot e Standard, atualize o cluster com a flag --enable-fqdn-network-policy:
```
gcloud container clusters update CLUSTER_NAME  \
    --enable-fqdn-network-policy
```
Substitua CLUSTER_NAME pelo nome do seu cluster.

Nota: a atualização do cluster e a instalação dos CRDs da política de rede FQDN podem demorar vários minutos a concluir. Um cluster regional do GKE demora mais tempo a ser atualizado com êxito do que um cluster zonal.
Apenas para clusters Standard, reinicie o DaemonSet do GKE Dataplane V2:anetd
```
kubectl rollout restart ds -n kube-system anetd
```
Nota: nos clusters do Autopilot, o plano de controlo do GKE reinicia automaticamente os nós após a ativação da funcionalidade de política de rede de NFDQ. O reinício do nó e a aplicação das políticas pelos novos nós podem demorar algumas horas. Para verificar se os nós foram reiniciados, use o comando kubectl get nodes e verifique o campo AGE de cada nó.

Crie um `FQDNNetworkPolicy`

Guarde o seguinte manifesto como fqdn-network-policy.yaml:
```
apiVersion: networking.gke.io/v1alpha1
kind: FQDNNetworkPolicy
metadata:
  name: allow-out-fqdnnp
spec:
  podSelector:
    matchLabels:
      app: curl-client
  egress:
  - matches:
    - pattern: "*.yourdomain.com"
    - name: "www.google.com"
    ports:
    - protocol: "TCP"
      port: 443
```
Este manifesto tem as seguintes propriedades:
- name: www.google.com: o nome do domínio totalmente qualificado. Os endereços IP fornecidos pelo servidor de nomes associado a www.google.com são permitidos. Tem de especificar name ou pattern, ou ambos.
- pattern: "*.yourdomain.com": os endereços IP fornecidos pelos servidores de nomes que correspondem a este padrão são permitidos. Pode usar as seguintes expressões regulares para a chave de padrão: ^([a-zA-Z0-9*]([-a-zA-Z0-9_*]*[a-zA-Z0-9*])*\.?)*$. Os critérios de correspondência são aditivos. Pode usar vários campos pattern. Tem de especificar name ou pattern, ou ambos.
- protocol: "TCP" e port: 443: especifica um protocolo e uma porta. Se um Pod tentar estabelecer uma ligação a endereços IP através desta combinação de protocolo e porta, a resolução de nomes funciona, mas o plano de dados bloqueia a ligação de saída. Este campo é opcional.

Verifique se a política de rede está a selecionar as suas cargas de trabalho:

kubectl describe fqdnnp

O resultado é semelhante ao seguinte:

Name:         allow-out-fqdnnp
Labels:       <none>
Annotations:  <none>
API Version:  networking.gke.io/v1alpha1
Kind:         FQDNNetworkPolicy
Metadata:
...
Spec:
  Egress:
    Matches:
      Pattern:  *.yourdomain.com
      Name:     www.google.com
    Ports:
      Port:      443
      Protocol:  TCP
  Pod Selector:
    Match Labels:
      App: curl-client
Events:     <none>

Elimine um `FQDNNetworkPolicy`

Pode eliminar um FQDNNetworkPolicy com o comando kubectl delete fqdnnp:

kubectl delete fqdnnp FQDN_POLICY_NAME

Substitua FQDN_POLICY_NAME pelo nome do seu FQDNNetworkPolicy.

O GKE elimina as regras da aplicação de políticas, mas as ligações existentes permanecem ativas até serem fechadas de acordo com as diretrizes do protocolo padrão conntrack.

Como funcionam as políticas de rede FQDN

FQDNNetworkPolicies são políticas apenas de saída que controlam para que pontos finais os pods selecionados podem enviar tráfego. Semelhante ao Kubernetes NetworkPolicy, um FQDNNetworkPolicy que seleciona uma carga de trabalho cria uma regra de recusa implícita para endpoints não especificados como destinos de saída permitidos. FQDNNetworkPolicies pode ser usado com o Kubernetes NetworkPolicies, conforme descrito em FQDNNetworkPolicy e NetworkPolicy.

As FQDNNetworkPolicies são aplicadas ao nível do endereço IP e da porta. Não são aplicadas através de informações de protocolo da camada 7 (por exemplo, o Request-URI num pedido HTTP). Os nomes de domínio especificados são traduzidos em endereços IP através das informações DNS fornecidas pelo fornecedor de DNS do cluster do GKE.

Pedidos DNS

Um FQDNNetworkPolicy ativo que seleciona cargas de trabalho não afeta a capacidade das cargas de trabalho de fazer pedidos DNS. Os comandos como nslookup ou dig funcionam em quaisquer domínios sem serem afetados pela política. No entanto, os pedidos subsequentes para os domínios de apoio do endereço IP que não estejam na lista de autorizações seriam ignorados.

Por exemplo, se um FQDNNetworkPolicy permitir a saída para www.github.com, os pedidos de DNS para todos os domínios são permitidos, mas o tráfego enviado para um endereço IP de apoio a twitter.com é rejeitado.

Expiração do TTL

FQDNNetworkPolicy respeita o TTL fornecido por um registo DNS. Se um Pod tentar contactar um endereço IP expirado após o tempo de vida (TTL) do registo DNS ter decorrido, as novas ligações são rejeitadas. As ligações de longa duração cuja duração exceda o TTL do registo DNS não devem sofrer interrupções de tráfego enquanto o conntrack considerar a ligação ainda ativa.

FQDNNetworkPolicy e NetworkPolicy

Quando um FQDNNetworkPolicy e um NetworkPolicy se aplicam ao mesmo Pod, o que significa que as etiquetas do Pod correspondem ao que está configurado nas políticas, o tráfego de saída é permitido desde que corresponda a uma das políticas. Não existe hierarquia entre a saída NetworkPolicies que especifica endereços IP ou seletores de etiquetas e FQDNNetworkPolicies.

Pontos finais de endereço IP partilhados (equilibradores de carga, CDN, gateway de VPN, etc.)

Muitos domínios não têm endereços IP dedicados que os suportem e, em vez disso, são expostos através de endereços IP partilhados. Isto é especialmente comum quando a aplicação é fornecida por um equilibrador de carga ou uma RFC. Por exemplo, as APIs (compute.googleapis.com, container.googleapis.com, etc.) não têm endereços IP exclusivos para cada API.Google Cloud Em alternativa, todas as APIs são expostas através de um intervalo partilhado.

Ao configurar o FQDNNetworkPolicies, é importante considerar se os domínios permitidos estão a usar endereços IP dedicados ou endereços IP partilhados. Como as restrições de origem cruzada são aplicadas ao nível do endereço IP e da porta, não conseguem distinguir entre vários domínios publicados pelo mesmo endereço IP.FQDNNetworkPolicies Permitir o acesso a um domínio suportado por um endereço IP partilhado permite que o seu pod comunique com todos os outros domínios publicados por esse endereço IP. Por exemplo, permitir o tráfego para compute.googleapis.com também permite que o Pod comunique com outras Google Cloud APIs.

CNAME Chasing

Se o objeto FQDN em FQDNNetworkPolicy incluir um domínio com CNAMEs no registo DNS, tem de configurar o FQDNNetworkPolicy com todos os nomes de domínio que o seu Pod pode consultar diretamente, incluindo todos os potenciais alias, para garantir um comportamento FQDNNetworkPolicy fiável.

Se as suas consultas de pods forem example.com, deve escrever example.com na regra. Mesmo que receba uma cadeia de alias dos servidores DNS a montante (por exemplo, example.com para example.cdn.com para 1.2.3.4), a política de rede de FQDN vai continuar a permitir a passagem do seu tráfego.

Problemas Conhecidos

Esta secção apresenta todos os problemas conhecidos para os nomes de domínio totalmente qualificados (FQDN).

A especificação de `protocol: ALL` faz com que a política seja ignorada

Este problema conhecido foi corrigido para as versões do GKE 1.27.10-gke.1055000+ e 1.28.3-gke.1055000+

Se criar uma FQDNNetworkPolicy que especifique protocol: ALL na secção ports, o GKE não aplica a política. Este problema ocorre devido a um problema com a análise da política. A especificação de TCP ou UDP não causa este problema.

Como solução alternativa, se não especificar um protocol na entrada ports, a regra corresponde a todos os protocolos por predefinição. A remoção do protocol: ALL contorna o problema de análise e o GKE aplica o FQDNNetworkPolicy.

Nas versões 1.27.10-gke.1055000+ e 1.28.3-gke.1055000+ do GKE, as políticas com protocol: ALL são analisadas e aplicadas corretamente.

O registo de NetworkPolicy causa registos incorretos ou em falta

Este problema conhecido foi corrigido para as versões do GKE 1.27.10-gke.1055000+ e 1.28.2-gke.1157000+

Se o seu cluster estiver a usar o registo da política de rede e as políticas de rede FQDN, existe um erro que pode causar entradas de registo em falta ou incorretas.

Quando usa o registo de políticas de rede sem delegado, os registos de políticas para ligações DNS que saem de uma carga de trabalho afirmam incorretamente que o tráfego foi rejeitado. O tráfego em si foi permitido (de acordo com o FQDNNetworkPolicy), mas os registos estavam incorretos.

Quando usa o registo da política de rede com delegação, faltam registos de políticas. O tráfego em si não é afetado.

Nas versões 1.27.10-gke.105500+ e 1.28.2-gke.1157000+ do GKE, este erro foi corrigido. As ligações DNS vão agora ser registadas corretamente como PERMITIDAS quando o tráfego for selecionado por um NetworkPolicy ou um FQDNNetworkPolicy.