Nesta página, descrevemos as regras de firewall da VPC de permissão de entrada que o Google Kubernetes Engine (GKE) cria automaticamente por padrão em Google Cloud.
Firewalls e firewalls de saída aplicáveis
O GKE usa regras de firewall da nuvem privada virtual (VPC) para controlar o tráfego de entrada e saída dos seus pods e nós. Por padrão, o GKE cria e gerencia automaticamente algumas regras de firewall para permitir o tráfego essencial, como a comunicação entre nós e pods, e o tráfego para o plano de controle do Kubernetes. Embora o GKE crie automaticamente regras de firewall da VPC de permissão de entrada para serviços do LoadBalancer por padrão, é possível desativar esse comportamento para gerenciar regras ou políticas de firewall manualmente ou usar recursos avançados de firewall.
As regras de firewall de entrada criadas pelo GKE não são as únicas aplicáveis aos nós em um cluster. O conjunto completo de regras de firewall aplicáveis para entrada e saída é definido com base em regras de políticas hierárquicas de firewall, políticas de firewall de rede global, políticas de firewall de rede regional e outras regras de firewall da VPC.
Planeje e crie a configuração para seu cluster, cargas de trabalho e serviços com os administradores de rede e engenheiros de segurança da sua organização. Entenda a política e a ordem de avaliação de regras do firewall para saber quais regras têm precedência.
O GKE cria apenas regras de firewall da VPC de entrada porque depende da regra de firewall de saída permitida implícita de menor prioridade.
Se você configurou regras de firewall de negação de saída na rede VPC do cluster, talvez seja necessário criar regras de permissão de saída para permitir a comunicação entre nós, pods e o plano de controle do cluster.
Por exemplo, se você criou uma regra de firewall de negação de saída para todos os protocolos
e portas e todos os endereços IP de destino, crie regras de firewall de permissão de saída
além das regras de entrada que o GKE
cria automaticamente. A conectividade com os endpoints do plano de controle sempre usa a porta de destino TCP 443, mas a conectividade entre os nós e os pods do cluster pode usar qualquer protocolo e porta de destino.
As ferramentas a seguir são úteis para determinar quais regras de firewall permitem ou negam o tráfego:
Regras de firewall
Por padrão, o GKE cria regras de firewall automaticamente ao criar os seguintes recursos:
- Clusters do GKE
- Serviços do GKE
- Gateways do GKE e HTTPRoutes
- Entradas do GKE
A menos que especificado de outra forma, a prioridade de todas as regras de firewall criadas automaticamente é 1.000, que é o valor padrão das regras de firewall. Para ter mais controle sobre o comportamento do firewall, crie regras de firewall com prioridade mais alta. As regras de firewall com prioridade mais alta são aplicadas antes da criação automática.
Regras de firewall do cluster do GKE
O GKE cria as seguintes regras de firewall de entrada ao criar um cluster:
| Nome | Finalidade | Origem | Meta (define o destino) | Protocolo e portas | Prioridade |
|---|---|---|---|---|---|
gke-[cluster-name]-[cluster-hash]-master |
Para clusters do Autopilot e do Standard que dependem do peering de rede VPC para a conectividade do endpoint particular do plano de controle. Permite que o plano de controle acesse o kubelet e o metrics-server nos nós do cluster. | Intervalo de endereços IP do plano de controle (/28) | Tag de nó | TCP: 443 (metrics-server) e TCP: 10250 (kubelet) | 1000 |
gke-[cluster-name]-[cluster-hash]-vms
|
Usado na comunicação intracluster necessária para o modelo de rede do Kubernetes. Permite que o software em execução nos nós envie pacotes, com origens correspondentes a endereços IP de nós para endereços IP de pods e nós no cluster. Por exemplo, o tráfego permitido por essa regra inclui:
|
O intervalo de endereços IP do nó ou um superconjunto desse intervalo:
|
Tag de nó | TCP: 1-65535, UDP: 1-65535, ICMP | 1000 |
gke-[cluster-name]-[cluster-hash]-all |
Permite tráfego entre todos os pods em um cluster, conforme exigido pelo modelo de rede do Kubernetes. |
CIDR do pod Para clusters com o CIDR de vários pods descontínuos ativado, todos os blocos de CIDR de pod usados pelo cluster. |
Tag de nó | TCP, UDP, SCTP, ICMP, ESP, AH | 1000 |
gke-[cluster-hash]-ipv6-all |
Apenas para clusters de rede de pilha dupla. Permite tráfego entre nós e pods em um cluster. |
Mesmo intervalo de endereços IP alocado em |
Tag de nó | TCP, UDP, SCTP, ICMP para IPv6, ESP, AH | 1000 |
gke-[cluster-name]-[cluster-hash]-inkubelet |
Permita o acesso à porta 10255 (porta somente leitura Kubelet) de CIDRs de pod internos e CIDRs de nós em novos clusters do GKE executando a versão 1.23.6 ou mais recente. Os clusters que executam versões posteriores à 1.26.4-gke.500 usam a porta autenticada do Kubelet (10250). Não adicione regras de firewall bloqueando 10250 no cluster. |
CIDRs de pods internos e de nós. |
Tag de nó | TCP: 10255 | 999 |
gke-[cluster-name]-[cluster-hash]-exkubelet |
Negue o acesso público à porta 10255 nos novos clusters do GKE executando a versão 1.23.6 ou posterior. |
0.0.0.0/0 |
Tag de nó | TCP: 10255 | 1000 |
Regras de firewall do serviço do GKE
O GKE cria as seguintes regras de firewall de entrada ao criar um Service. É possível impedir a criação de algumas dessas regras de firewall gerenciando a criação de regras de firewall da VPC.
| Nome | Finalidade | Origem | Meta (define o destino) | Protocolo e portas |
|---|---|---|---|---|
k8s-fw-[loadbalancer-hash] |
Permite que o tráfego de entrada chegue a um serviço. | Fonte: spec.loadBalancerSourceRanges. Se spec.loadBalancerSourceRanges for omitido, o padrão será 0.0.0.0/0.
Veja mais detalhes em Regras de firewall e lista de permissões de endereços IP de origem. |
Endereço IP virtual do balanceador de carga | TCP e UDP nas portas especificadas no manifesto do Serviço. |
k8s-[cluster-id]-node-http-hc |
Permite verificações de integridade
de um serviço de balanceador de carga de rede de passagem externo quando externalTrafficPolicy
está definido como Cluster. |
|
Endereço IP virtual do balanceador de carga | TCP: 10256 |
k8s-[loadbalancer-hash]-http-hc |
Permite verificações de integridade
de um serviço de balanceador de carga de rede de passagem externo quando externalTrafficPolicy
está definido como Local. |
|
Tag de nó | Porta TCP definida por spec.healthCheckNodePort. Se não for especificado, o plano de controle do Kubernetes atribuirá uma porta de verificação de integridade a partir do intervalo de portas do nó.
Confira mais detalhes em Porta de verificação de integridade. |
k8s-[cluster-id]-node-hc |
Permite verificações de integridade
de um serviço de balanceador de carga de rede de passagem interno quando externalTrafficPolicy
está definido como Cluster.
|
|
Tag de nó | TCP: 10256 |
[loadbalancer-hash]-hc |
Permite verificações de integridade
de um serviço de balanceador de carga de rede de passagem interno quando externalTrafficPolicy está definido como
Local.
|
|
Tag de nó | Porta TCP definida por spec.healthCheckNodePort. Se não for especificado, o plano de controle do Kubernetes atribuirá uma porta de verificação de integridade a partir do intervalo de portas do nó.
Confira mais detalhes em Porta de verificação de integridade. |
k8s2-[cluster-id]-[namespace]-[service-name]-[suffixhash] |
Permite que o tráfego de entrada alcance um serviço quando uma das seguintes opções for ativada:
|
Fonte: spec.loadBalancerSourceRanges. Se spec.loadBalancerSourceRanges for omitido, o padrão será 0.0.0.0/0.
Veja mais detalhes em Regras de firewall e lista de permissões de endereços IP de origem. |
Endereço IP virtual do balanceador de carga | TCP e UDP nas portas especificadas no manifesto do serviço. |
k8s2-[cluster-id]-[namespace]-[service-name]-[suffixhash]-fw |
Permite verificações de integridade
do serviço quando externalTrafficPolicy está definido como
Local e qualquer um dos seguintes itens está ativado:
|
|
Endereço IP virtual do balanceador de carga | Porta TCP definida por spec.healthCheckNodePort. Se não for especificado, o plano de controle do Kubernetes atribuirá uma porta de verificação de integridade a partir do intervalo de portas do nó.
Confira mais detalhes em Porta de verificação de integridade. |
k8s2-[cluster-id]-l4-shared-hc-fw |
Permite verificações de integridade
do serviço quando externalTrafficPolicy está definido como
Cluster e qualquer um dos seguintes itens está ativado:
|
|
Tag de nó | TCP: 10256 |
gke-[cluster-name]-[cluster-hash]-mcsd |
Permite que o plano de controle acesse o kubelet e o servidor de métricas nos nós do cluster para os serviços de vários clusters. Essa regra tem uma prioridade de 900. | Endereços IP de verificação de integridade | Tag de nó | TCP, UDP, SCTP, ICMP, ESP, AH |
Regras de firewall do gateway do GKE
O GKE cria as seguintes regras de firewall de gateway ao criar recursos Gateway e HTTPRoute:
| Nome | Finalidade | Origem | Meta (define o destino) | Protocolo e portas |
|---|---|---|---|---|
|
Permite as verificações de integridade de um grupo de endpoints de rede (NEG). O controlador de gateway cria essa regra quando o primeiro recurso de gateway é criado. O controlador de gateway poderá atualizar essa regra se forem criados mais recursos de gateway. |
|
Tag de nó | TCP: todas as portas de destino do contêiner (para NEGs) |
Regras de firewall de entrada do GKE
O GKE cria as seguintes regras de firewall de entrada ao criar uma Entrada:
| Nome | Finalidade | Origem | Meta (define o destino) | Protocolo e portas |
|---|---|---|---|---|
k8s-fw-l7-[random-hash] |
Permite verificações de integridade
de um serviço O controlador de Entrada cria essa regra durante a criação do primeiro recurso de Entrada. O controlador do Ingress poderá atualizar essa regra se mais recursos do Ingress forem criados. |
|
Tag de nó | TCP: 30000-32767, TCP:80 (para balanceadores de carga de aplicativo internos), TCP: todas as portas de destino do contêiner (para NEGs) |
Gerenciar a criação de regras de firewall da VPC
Por padrão, o GKE cria automaticamente regras de firewall da VPC de permissão de entrada para todos os serviços de LoadBalancer. Se você quiser gerenciar as regras de firewall para serviços de LoadBalancer por conta própria, desative a criação automática de regras de firewall da VPC.
A desativação da criação automática de regras de firewall da VPC para serviços do LoadBalancer se aplica apenas ao seguinte:
- Serviços LoadBalancer internos usando a subconfiguração do GKE
- Serviços LoadBalancer externos baseados em serviço de back-end
Para saber como desativar regras de firewall, consulte Regras de firewall gerenciadas pelo usuário para serviços LoadBalancer do GKE.
VPC compartilhada
Se você estiver usando serviços de Ingress ou LoadBalancer e tiver um cluster localizado em uma VPC compartilhada usando uma rede VPC compartilhada, a conta de serviço do GKE no projeto de serviço não poderá criar nem atualizar regras de firewall de permissão de entrada no projeto host. É possível conceder à conta de serviço do GKE permissões em um projeto de serviço para criar e gerenciar os recursos do firewall. Para mais informações, consulte VPC compartilhada.
Regra de firewall necessária para a sub-rede expandida
Se você
expandir o intervalo IPv4 principal da sub-rede do cluster, o GKE não atualizará automaticamente o intervalo de origem da
regra de firewall gke-[cluster-name]-[cluster-hash]-vms. Como os nós no
cluster podem receber endereços IPv4 da parte expandida do intervalo IPv4
principal da sub-rede, é necessário criar manualmente uma regra de firewall para permitir
a comunicação entre os nós do cluster.
A regra de firewall de entrada que você precisa criar precisa permitir pacotes TCP e ICMP do intervalo de origem IPv4 da sub-rede primária expandida e precisa se aplicar pelo menos a todos os nós no cluster.
Para criar uma regra de firewall de entrada que se aplique apenas aos nós do cluster, defina o destino da regra de firewall como a mesma tag de destino usada pela regra de firewall gke-[cluster-name]-[cluster-hash]-vms criada automaticamente por seu cluster.
A seguir
- Leia uma visão geral da rede no GKE.
- Saiba mais sobre Como configurar políticas de rede para aplicativos.
- Saiba mais sobre outras regras de firewall já preenchidas em Google Cloud.
- Saiba mais sobre Como criar regras de firewall em projetos que usam a VPC compartilhada.