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.
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 KubernetesNetworkPolicy
em vez de umFQDNNetworkPolicy
. - 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 KubernetesNetworkPolicy
. - 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 aapi.company.com
oustore.company.com
, mas não aeu.api.company.com
oucompany.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.Apenas para clusters Standard, reinicie o DaemonSet do GKE Dataplane V2:
anetd
kubectl rollout restart ds -n kube-system anetd
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 especificarname
oupattern
, 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 campospattern
. Tem de especificarname
oupattern
, ou ambos.protocol: "TCP"
eport: 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
.
O que se segue?
- Leia a documentação do Kubernetes acerca das políticas de rede
- Use as estatísticas de segurança para explorar outras formas de reforçar a sua infraestrutura