Segurança do gateway

Nesta página, descrevemos métodos diferentes para proteger gateways no Google Kubernetes Engine (GKE). Saiba como proteger um gateway.

Como funciona a segurança do gateway

Um gateway representa o front-end de um balanceador de carga. Dependendo dos requisitos de segurança e compliance, é possível proteger o tráfego por um gateway de duas maneiras principais:

  • Encerramento de TLS: o gateway encerra as conexões TLS do cliente no front-end do gateway usando certificados SSL gerenciados ou autogerenciados. O gateway pode criptografar novamente o tráfego entre o gateway e os pods de back-end usando uma BackendTLSPolicy.
  • Passagem de TLS: o tráfego TLS criptografado passa diretamente pelo gateway para os pods de back-end sem que o balanceador de carga encerre ou descriptografe o tráfego. Use os recursos TLSRoute para rotear o tráfego com base no nome do host da indicação de nome do servidor (SNI, na sigla em inglês).

Nesta página, descrevemos como proteger o caminho do cliente para o gateway usando certificados enviados e gerenciados no nível do gateway e como configurar a passagem de TLS de ponta a ponta. Para saber como proteger o tráfego do gateway para o pod com o término de TLS, consulte Proteger o balanceador de carga ao tráfego de aplicativos usando TLS.

Término de TLS em comparação com passagem de TLS

O gateway do GKE é compatível com dois modos de operação de TLS distintos, dependendo se o TLS é descriptografado no balanceador de carga ou transmitido diretamente para as cargas de trabalho de back-end: término de TLS e passagem de TLS.

término de TLS

Com o término de TLS, o gateway encerra as conexões TLS dos clientes no front-end do balanceador de carga.

Ao configurar um listener de gateway com o campo tls.mode definido como Terminate e o campo protocol definido como HTTPS, você anexa certificados TLS diretamente ao gateway usando secrets do Kubernetes, certificados SSL ou o Certificate Manager.

As principais características do término de TLS incluem:

  • Inspeção da camada 7: como o gateway descriptografa o tráfego do cliente, ele pode avaliar os atributos de solicitação HTTP (como cabeçalhos, caminhos e métodos) e rotear o tráfego usando recursos HTTPRoute.
  • Segurança de borda: permite a integração com as políticas de segurança do Google Cloud Armor, as regras do firewall de aplicativos da Web (WAF) e o armazenamento em cache de borda do Cloud CDN.
  • Criptografia de back-end com BackendTLSPolicy: se as cargas de trabalho exigirem criptografia de ponta a ponta em trânsito, configure um recurso BackendTLSPolicy para criptografar novamente o tráfego entre o gateway e os pods de back-end.

O diagrama a seguir mostra como um gateway do GKE criptografa os dois caminhos de tráfego quando você usa término de TLS com criptografia de back-end. Um cliente externo envia uma solicitação HTTPS criptografada (https://example.com) para o gateway em uma rede de nuvem privada virtual (VPC), em que o balanceador de carga encerra a conexão TLS. Em seguida, o balanceador de carga estabelece uma conexão separada e criptografada novamente para encaminhar o tráfego para os pods de back-end Store no cluster do GKE:

Criptografia de cliente para gateway e de gateway para back-end com término de TLS

Além da criptografia, é possível proteger o caminho do cliente para o gateway usando políticas de autorização. As políticas de autorização permitem uma arquitetura de confiança zero, inspecionando as solicitações recebidas e aplicando o controle de acesso com base nas identidades do cliente, nos cabeçalhos HTTP e nos caminhos solicitados antes que o tráfego seja roteado para os pods de back-end.

Para mais informações sobre como configurar término de TLS e o TLS de back-end, consulte Proteger um gateway.

Passagem de TLS

Com a passagem de TLS, o gateway faz o proxy do tráfego TLS criptografado diretamente para as cargas de trabalho de back-end sem descriptografar o payload no balanceador de carga.

Quando você configura um listener de gateway com o campo tls.mode definido como Passthrough e o campo protocol definido como TLS, o gateway não encerra o TLS nem mantém certificados SSL. Em vez disso, o balanceador de carga inspeciona apenas o nome do host da indicação de nome do servidor (SNI, na sigla em inglês) não criptografado no handshake de TLS ClientHello e roteia o fluxo TCP criptografado bruto para os pods de back-end usando recursos TLSRoute.

As principais características da passagem de TLS incluem:

  • Criptografia de ponta a ponta: o tráfego permanece criptografado durante todo o trânsito do cliente para os pods de back-end. O aplicativo de back-end gerencia certificados, encerra o TLS e descriptografa o payload.
  • Não é necessário gerenciar certificados no gateway: não é preciso anexar certificados ou secrets do Kubernetes ao listener do gateway.
  • Proxy da camada 4: o balanceador de carga encaminha streams TCP criptografados e roteia o tráfego com base em metadados de handshake de TLS não criptografados (como o nome do host SNI) usando recursos TLSRoute.
  • Compensações de segurança: a passagem de TLS funciona bem para requisitos de conformidade em que não é possível compartilhar chaves privadas com a infraestrutura em nuvem ou para protocolos não HTTP baseados em TLS. No entanto, ele impede a inspeção do balanceador de carga da camada 7 e os serviços de segurança de borda, como as regras de WAF do Google Cloud Armor.

O diagrama a seguir mostra como o gateway criptografa e roteia o tráfego do cliente para os pods de back-end ao usar a passagem de TLS. Um cliente envia uma solicitação TLS criptografada com o nome do host SNI store.example.com para o gateway, que encaminha o stream criptografado sem descriptografia diretamente para os pods Store de destino:

Passagem de TLS criptografada de ponta a ponta do cliente para os pods de back-end

Para mais informações sobre como implantar um gateway de passagem de TLS com TLSRoute, consulte Implantar um gateway de passagem de TLS.

Vantagens

É possível proteger um aplicativo de várias maneiras usando a API Gateway, que oferece flexibilidade para diferentes papéis que interagem com o gateway.

Quem é o proprietário da configuração do domínio e do TLS?

O modelo da API Gateway introduz dois papéis que usam ou implantam gateways:

  • Administrador da plataforma: o operador do cluster é o administrador de clusters inteiros. Elas gerenciam políticas, acesso à rede e permissões de apps.
  • Desenvolvedor de aplicativos: o desenvolvedor do aplicativo define o aplicativo e as configurações de serviço.

O diagrama a seguir mostra os campos nos recursos Gateway e HTTPRoute que influenciam a propriedade TLS e a propriedade do domínio de dois aplicativos (store-v1 e store-v2).

No diagrama, o operador do cluster controla:

  • Quais domínios os desenvolvedores de aplicativos podem usar nos apps deles em cada namespace.
  • Os certificados específicos que encerram domínios diferentes.
  • Certificados fornecidos pelo proprietário do gateway.
  • Se os proprietários de HTTPRoute podem especificar seus próprios nomes de host para geração de certificados.

Os desenvolvedores de aplicativos controlam o nome do host que gera um certificado, se a definição de gateway permitir.

Essa separação de tarefas operacionais permite que os desenvolvedores de aplicativos implantem e gerenciem os próprios HTTPRoute para ter um controle mais distribuído, além de permitir que os administradores da plataforma implantem e gerenciem Gateways para controle centralizado do TLS.

Gerenciamento de certificados de gateway

É possível proteger os gateways usando qualquer um dos seguintes métodos:

Se você usar os secrets do Kubernetes ou os recursos SslCertificate da API Compute Engine, poderá anexar no máximo 15 certificados a um único gateway.

Com o Certificate Manager, é possível anexar até 10.000.000 certificados por balanceador de carga, caso você solicite um aumento de cota.

Para saber mais sobre os certificados SSL do Google Cloud , consulte Visão geral dos certificados SSL.

Secrets do Kubernetes

A especificação da API Gateway é compatível com o Secrets do Kubernetes para armazenar e anexar certificados ao Gateways. É possível associar um ou mais secrets do Kubernetes a um gateway usando o campo Gateway.spec.tls.certificateRef.

Os recursos de gateway protegidos pelo Secrets do Kubernetes têm os seguintes requisitos:

  • Defina o listener de gateway port e protocol a 443 e HTTPS.
  • Defina o campo listener.tls.mode como Terminate.
  • É preciso fazer referência às credenciais TLS no bloco listeners.tls.

Os recursos de gateway protegidos pelo Secrets do Kubernetes têm as seguintes limitações:

  • Somente listeners HTTPS encerram tráfego usando os Secrets especificados, embora é possível especificar vários listeners com uma combinação de HTTP e HTTPS.
  • Se você tiver vários listeners usando HTTPS no mesmo gateway, cada um deles precisará ter um nome de host exclusivo.
  • Só é possível omitir um único nome do host ou atribuir * para cada par de porta e protocolo.
  • Só é possível atribuir um certificado padrão a cada gateway.

Para saber como proteger um gateway usando um secret do Kubernetes, consulte Proteger um gateway usando um secret do Kubernetes.

Certificados SSL

Os certificados SSL armazenam e enviam certificados para balanceadores de carga. Um certificado SSL pode ser autogerenciado ou gerenciado pelo Google.

  • Os certificados SSL autogerenciados são obtidos, provisionados e renovados por você.
  • Os certificados SSL gerenciados pelo Google são aqueles que o Google Cloud recebe, gerencia e renova automaticamente.

Para saber mais sobre as diferenças entre esses dois tipos de certificados, consulte Visão geral dos certificados SSL.

O escopo e o local do certificado SSL precisam corresponder ao escopo e ao local do gateway que está usando o certificado. Por exemplo, um certificado SSL global não pode ser usado por um gateway regional.

A tabela a seguir lista os requisitos de escopo e localização dos certificados SSL para cada GatewayClass:

GatewayClass Escopo do certificado SSL Local do certificado SSL
gke-l7-global-external-managed Certificado SSL global Global
gke-l7-global-external-managed-mc
gke-l7-gxlb
gke-l7-gxlb-mc
gke-l7-regional-external-managed Certificado SSL regional Precisa ser a mesma região do gateway
gke-l7-regional-external-managed-mc
gke-l7-cross-regional-internal-managed-mc
gke-l7-rilb
gke-l7-rilb-mc

Os certificados SSL gerenciados pelo Google não são compatíveis com os gateways regionais. Para proteger gateways regionais, use o Certificate Manager.

Para saber como proteger um gateway usando um certificado SSL, consulte Proteger um gateway usando um certificado SSL.

Certificate Manager

O Certificate Manager é um local centralizado para gerenciar seus certificados TLS.

Quando você protege um gateway usando o Certificate Manager, é possível fazer o seguinte:

  • Faça referência a um CertificateMap diretamente de um gateway que você criou no Certificate Manager.
  • Gerenciar seus próprios certificados.
  • Melhore os tempos de propagação de certificados.
  • Usar o Cloud Monitoring para certificados expirados e propagação de certificados.

O Certificate Manager é compatível com certificados SSL autogerenciados e gerenciados pelo Google. Para saber como proteger um gateway usando o Certificate Manager, consulte Proteger um gateway usando o Certificate Manager.

Compatibilidade com TLS da GatewayClass

Na tabela a seguir, descrevemos os métodos de encerramento de TLS compatíveis com o GKE para cada GatewayClass:

GatewayClass gke-l7-global-external-managed
gke-l7-global-external-managed-mc
gke-l7-gxlb
gke-l7-gxlb-mc 		gke-l7-regional-external-managed
gke-l7-regional-external-managed-mc
gke-l7-rilb
gke-l7-rilb-mc 		gke-l7-cross-regional-internal-managed-mc
TLS do cliente para o gateway Compatível Compatível
Gateway para TLS de back-end Compatível Compatível
Recurso de certificadoGoogle Cloud Certificado SSL global
CertificateMap		 Certificado SSL regional
Passagem de TLS (TLSRoute) Não compatível Compatível Compatível
Certificados autogerenciados com secrets do Kubernetes Compatível Compatível Não compatível
Certificados SSL autogerenciados do Compute Engine Compatível Compatível Não compatível
Certificados SSL do Compute Engine gerenciados pelo Google Compatível Não compatível Não compatível
Certificados SSL autogerenciados com o Certificate Manager Compatível Compatível Compatível
Certificados SSL gerenciados pelo Google com o Certificate Manager Compatível Compatível Compatível

Autorização e controle de acesso

Os gateways do GKE são compatíveis com o controle de acesso baseado em identidade usando o recurso personalizado GCPAuthzPolicy. Esse recurso permite que os administradores da plataforma definam regras explícitas de ALLOW ou DENY para o tráfego norte-sul.

Além disso, os gateways podem ser integrados às extensões de serviço usando o recurso GCPAuthzExtension. Esse recurso permite que o gateway faça chamadas inline para mecanismos de autorização externos, personalizados ou de terceiros (como o Identity-Aware Proxy) para avaliar solicitações em tempo real.

A seguir