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. Há dois caminhos que podem ser protegidos com autenticação e criptografia para gateways:

  • Cliente para o gateway: tráfego originado no cliente e encerrado no gateway.
  • Gateway para pod: o tráfego se originou no Gateway e foi encerrado nos pods de back-end.

O diagrama a seguir mostra os dois caminhos para autenticar e criptografar gateways:

Nesta página, descrevemos como proteger o caminho do cliente para o gateway usando certificados enviados e gerenciados no nível do gateway. Para saber como proteger o gateway para o tráfego do pod, consulte Proteger o balanceador de carga ao tráfego de aplicativos usando 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 a configuração do 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.

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 de 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.

O escopo e o local do certificado SSL precisam corresponder ao escopo e ao local do gateway que está usando o certificado.

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-regional-external-managed Certificado SSL regional Precisa ser a mesma região do gateway
gke-l7-rilb

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

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-regional-external-managed
gke-l7-rilb
TLS do cliente para o gateway Compatível
Gateway para TLS de back-end Compatível
Recurso de certificado do Google Cloud Certificado SSL regional
Certificados autogerenciados com secrets do Kubernetes Compatível
Certificados SSL autogerenciados do Compute Engine Compatível

A seguir