Segurança do gateway

Esta página descreve diferentes métodos para proteger gateways no Google Kubernetes Engine (GKE). Também pode saber como proteger um gateway.

Como funciona a segurança do gateway

Um Gateway representa o front-end de um balanceador de carga. Existem dois caminhos que pode proteger com autenticação e encriptação para gateways:

  • Cliente para gateway: tráfego originado no cliente e terminado no gateway.
  • Entrada para o pod: tráfego originado na entrada e terminado nos pods de back-end.

O diagrama seguinte mostra os dois caminhos para autenticar e encriptar gateways:

Esta página descreve como proteger o caminho do cliente para o gateway através de certificados carregados e geridos ao nível do gateway. Para saber como proteger o tráfego de gateway para pod, consulte o artigo Proteja o balanceador de carga para o tráfego de aplicações através do TLS.

Vantagens

Pode proteger uma aplicação de muitas formas diferentes através da API Gateway, que oferece flexibilidade a diferentes funções que interagem com o gateway.

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

O modelo da API Gateway introduz duas funções que usam ou implementam gateways:

  • Administrador da plataforma: o operador do cluster é o administrador de todos os clusters. Gerem políticas, acesso à rede e autorizações de aplicações.
  • Programador de aplicações: o programador de aplicações define a respetiva aplicação e configuração do serviço.

O diagrama seguinte mostra os campos nos recursos Gateway e HTTPRoute que influenciam o TLS e a propriedade do domínio para duas aplicações, store-v1 e store-v2.

No diagrama, o operador do cluster controla:

  • Que domínios os programadores de aplicações podem usar para as respetivas apps em cada espaço de nomes.
  • Os certificados específicos que terminam domínios diferentes.
  • Certificados fornecidos pelo proprietário do gateway.
  • Se os proprietários de HTTPRoute podem especificar os seus próprios nomes de anfitrião para a geração de certificados.

Os programadores de aplicações controlam o nome do anfitrião que gera um certificado, se a definição de gateway o permitir.

Esta separação de tarefas operacionais permite que os programadores de aplicações implementem e geram a sua própria HTTPRoute para um controlo mais distribuído e permite que os administradores da plataforma implementem e geram gateways para um controlo centralizado do TLS.

Gestão de certificados de gateway

Pode proteger as gateways através de qualquer um dos seguintes métodos:

Se usar segredos do Kubernetes ou recursos SslCertificate da API Compute Engine, pode anexar, no máximo, 15 certificados a um único gateway.

O Gestor de certificados permite-lhe anexar até 10 000 000 de certificados por equilibrador de carga, se pedir um aumento da quota.

Para saber mais acerca dos Google Cloud certificados SSL, consulte o artigo Vista geral dos certificados SSL.

Segredos do Kubernetes

A especificação da API Gateway suporta segredos do Kubernetes para armazenar e anexar certificados a gateways. Pode associar um ou mais segredos do Kubernetes a um gateway através do campo Gateway.spec.tls.certificateRef.

Os recursos de gateway protegidos através de segredos do Kubernetes têm os seguintes requisitos:

  • Tem de definir o ouvinte do gateway port e protocol para 443 e HTTPS.
  • Tem de definir o campo listener.tls.mode como Terminate.
  • Tem de fazer referência às credenciais TLS no bloco listeners.tls.

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

  • Apenas os ouvintes HTTPS terminam o tráfego através dos segredos especificados, embora possa especificar vários ouvintes com uma combinação de HTTP e HTTPS.
  • Se tiver vários ouvintes a usar HTTPS na mesma gateway, cada ouvinte tem de ter um nome de anfitrião exclusivo.
  • Só pode omitir um único nome de anfitrião ou atribuir * para cada par de porta e protocolo.
  • Só pode atribuir um certificado predefinido a cada gateway.

Para saber como proteger um gateway com um segredo do Kubernetes, consulte o artigo Proteja um gateway com um segredo do Kubernetes.

Certificados SSL

Os certificados SSL armazenam e fornecem certificados aos equilibradores de carga. Um certificado SSL pode ser autogerido ou gerido pela Google.

  • Os certificados SSL autogeridos são certificados que obtém, aprovisiona e renova por si.
  • Os certificados SSL geridos pela Google são certificados que a Google Google Cloud obtém, gere e renova automaticamente.

Para saber mais sobre as diferenças entre estes dois tipos de certificados, consulte o artigo Vista geral dos certificados SSL.

O âmbito e a localização do certificado SSL têm de corresponder ao âmbito e à localização do gateway que o está a usar. Por exemplo, um certificado SSL global não pode ser usado por um gateway regional.

A tabela seguinte apresenta os requisitos de âmbito e localização dos certificados SSL para cada GatewayClass:

GatewayClass Âmbito do certificado SSL Localização 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 Tem de ser a mesma região que o gateway
gke-l7-regional-external-managed-mc
gke-l7-rilb
gke-l7-rilb-mc

Os certificados SSL geridos pela Google não são compatíveis com gateways regionais. Para proteger gateways regionais, use o gestor de certificados.

Para saber como proteger um gateway com um certificado SSL, consulte o artigo Proteja um gateway com um certificado SSL.

Gestor de certificados

O Gestor de certificados é uma localização centralizada para gerir os seus certificados TLS.

Quando protege um gateway com o Gestor de certificados, pode fazer o seguinte:

  • Referencie um CertificateMap diretamente a partir de um gateway que criou no Gestor de certificados.
  • Faça a gestão dos seus próprios certificados.
  • Melhorar os tempos de propagação de certificados.
  • Use o Cloud Monitoring para certificados expirados e propagação de certificados.

O Gestor de certificados suporta certificados SSL autogeridos e geridos pela Google. Para saber como proteger um gateway com o gestor de certificados, consulte o artigo Proteja um gateway com o gestor de certificados.

Suporte de TLS GatewayClass

A tabela seguinte descreve os métodos de terminação de TLS que o GKE suporta 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 de cliente para gateway Suportado Suportado
Gateway para TLS de back-end Suportado Suportado
Google Cloud recurso de certificado Certificado SSL global
CertificateMap		 Certificado SSL regional
Certificados autogeridos com secrets do Kubernetes Suportado Suportado
Certificados SSL do Compute Engine autogeridos Suportado Suportado
Certificados SSL do Compute Engine geridos pela Google Suportado Não suportado
Certificados SSL autogeridos com o Gestor de certificados Suportado Suportado
Certificados SSL geridos pela Google com o Gestor de certificados Suportado Suportado

O que se segue?