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.

Benefícios

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

Com o Gerenciador de certificados, é 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 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.

Um certificado SSL pode ser autogerenciado ou gerenciado pelo Google.

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-rilb
gke-l7-rilb-mc
Os certificados SSL gerenciados pelo Google não são compatíveis com os gateways regionais.

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

Gerenciador de certificados

O Gerenciador de certificados é um local centralizado para gerenciar seus certificados TLS.

Quando você protege um gateway usando o Gerenciador de certificados, é possível fazer o seguinte:

  • Faça referência a um CertificateMap diretamente de um gateway que você criou no gerenciador de certificados.
  • 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 Gerenciador de certificados é compatível com certificados SSL autogerenciados e gerenciados pelo Google.

Para saber como proteger um gateway usando o Gerenciador de certificados, consulte Proteger um gateway usando o Gerenciador de certificados.

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
TLS do cliente para o gateway Compatível Compatível
Gateway para TLS de back-end Compatível Compatível
Recurso de certificado do Google Cloud Certificado SSL global
CertificateMap		 Certificado SSL regional
Certificados autogerenciados com secrets do Kubernetes Compatível Compatível
Certificados SSL autogerenciados do Compute Engine Compatível Compatível
Certificados SSL do Compute Engine gerenciados pelo Google Compatível Não compatível
Certificados SSL autogerenciados com o Gerenciador de certificados Compatível Compatível
Certificados SSL gerenciados pelo Google com o Gerenciador de certificados Compatível Compatível

A seguir