Nesta página, você encontra as regras de firewall que o Google Kubernetes Engine (GKE) cria automaticamente no Google Cloud.
Além das regras específicas do GKE listadas nesta página, os projetos padrão do Google Cloud incluem várias regras de firewall pré-preenchidas. Geralmente, os clusters do GKE são implantados em uma rede VPC. Essas regras concedem acesso à rede essencial para clusters do GKE. Essas regras são suficientes para a operação básica do cluster, mas talvez seja necessário criar outras regras, dependendo das suas necessidades específicas.
Regras de firewall
O GKE cria regras de firewall automaticamente ao criar os recursos a seguir:
- 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 |
Apenas para clusters particulares do Autopilot e Standard. 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 Serviço:
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 spec.healthCheckNodePort for omitido, o padrão será o número da porta TCP 10256 .
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 spec.healthCheckNodePort for omitido, o padrão será o número da porta TCP 10256 .
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 spec.healthCheckNodePort for omitido, o padrão será o número da porta TCP 10256 .
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) |
VPC compartilhada
Quando um cluster localizado em uma VPC compartilhada usa uma rede VPC compartilhada, o controlador de Entrada não pode usar a conta de serviço do GKE no projeto de serviço para criar e atualizar as 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.
Ordem de avaliação da regra
Se você estiver usando políticas de firewall além das regras de firewall da VPC, por padrão, o Google Cloud avaliará as regras de firewall antes das políticas de firewall de rede (globais e regionais). Se você alterar a ordem de avaliação de regras, o tráfego talvez não alcance seus clusters do GKE. Para mais informações, consulte Ordem de avaliação de políticas e regras.
Geração de registros de regras de Firewall
A geração de registros de regras de firewall está desativada por padrão. Para ativar a geração de registros para uma regra de firewall, use o comando --enable-logging
.
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 no Google Cloud.
- Saiba mais sobre Como criar regras de firewall em projetos que usam a VPC compartilhada.