Usar vários certificados SSL no balanceamento de carga HTTPS com o Ingress

Esta página mostra como configurar vários certificados SSL para recursos de entrada em clusters do Google Kubernetes Engine (GKE).

Vista geral

Se quiser aceitar pedidos HTTPS dos seus clientes, o Application Load Balancer tem de ter um certificado para poder provar a sua identidade aos seus clientes. O balanceador de carga também tem de ter uma chave privada para concluir o handshake HTTPS.

Quando o balanceador de carga aceita um pedido HTTPS de um cliente, o tráfego entre o cliente e o balanceador de carga é encriptado através do protocolo TLS. No entanto, o balanceador de carga termina a encriptação TLS e encaminha o pedido sem encriptação para a aplicação. Quando configura um balanceador de carga de aplicações através do Ingress, pode configurar o balanceador de carga para apresentar até 15 certificados TLS ao cliente.

O balanceador de carga usa a Indicação do nome do servidor (SNI) para determinar que certificado apresentar ao cliente, com base no nome do domínio na negociação TLS. Se o cliente não usar SNI ou se usar um nome de domínio que não corresponda ao nome comum (CN) num dos certificados, o balanceador de carga usa o primeiro certificado indicado no Ingress.

O diagrama seguinte mostra o balanceador de carga a enviar tráfego para diferentes back-ends, consoante o nome do domínio usado no pedido:

Pode fornecer um Application Load Balancer com certificados SSL através dos seguintes métodos:

• Certificados SSL geridos pela Google. Consulte a página de certificados geridos para ver informações sobre como os usar.

• Trusted Cloud by S3NS Certificado SSL gerido por si. O certificado SSL usa um certificado pré-partilhado que carrega para o seu Trusted Cloud by S3NS projeto.

• Kubernetes Secrets. O segredo contém um certificado e uma chave que cria. Adicione o nome do segredo ao campo tls do manifesto do Ingress.

Pode usar mais do que um método no mesmo Ingress. Isto permite migrações sem tempo de inatividade entre métodos.

O panorama geral

Segue-se uma vista geral dos passos descritos neste documento:

1. Crie uma implementação.

2. Crie um serviço.

3. Crie dois ficheiros de certificado e dois ficheiros de chave ou dois objetos ManagedCertificate. Tem de configurar estes certificados no mesmo projeto e no mesmo espaço de nomes onde o equilibrador de carga está implementado.

4. Crie um Ingress que use segredos ou certificados partilhados previamente. Quando cria o Ingress, o GKE cria e configura um Application Load Balancer.

5. Teste o balanceador de carga de aplicações.

Antes de começar

Antes de começar, certifique-se de que realizou as seguintes tarefas:

• Ative a API Google Kubernetes Engine.
Ative a API Google Kubernetes Engine
• Se quiser usar a CLI gcloud para esta tarefa, instale-a e, em seguida, inicialize-a. Se instalou anteriormente a CLI gcloud, execute gcloud components update para obter a versão mais recente.

• Tem de ser proprietário de dois nomes de domínio. Os nomes de domínio não podem ter mais de 63 carateres.
• Certifique-se de que tem um cluster do Autopilot ou Standard existente. Para criar um novo cluster, consulte o artigo Crie um cluster do Autopilot.

Limitações

• Os certificados geridos pela Google só são suportados com o GKE Ingress através do Application Load Balancer externo. Os certificados geridos pela Google não suportam controladores Ingress de terceiros.

• Para balanceadores de carga de aplicações internos, tem de desativar o HTTP no manifesto de entrada. Isto não é necessário para o balanceador de carga externo.

• Não deve alterar nem atualizar manualmente a configuração do Application Load Balancer. Isto significa que não pode editar nenhum dos componentes do equilibrador de carga, incluindo proxies de destino, mapas de URLs e serviços de back-end. Quaisquer alterações que fizer são substituídas pelo GKE.

Crie uma implementação

1. Guarde o seguinte manifesto como my-mc-deployment.yaml:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: my-mc-deployment
   spec:
     selector:
       matchLabels:
         app: products
         department: sales
     replicas: 3
     template:
       metadata:
         labels:
           app: products
           department: sales
       spec:
         containers:
         - name: hello
           image: "us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0"
           env:
           - name: "PORT"
             value: "50001"
         - name: hello-again
           image: "us-docker.pkg.dev/google-samples/containers/gke/hello-app:2.0"
           env:
           - name: "PORT"
             value: "50002"
   

   Este manifesto descreve uma implementação com três pods. Cada pod tem dois contentores. Um contentor executa o hello-app:1.0 e ouve na porta TCP 50001. O outro contentor executa o hello-app:2.0 e ouve na porta TCP 50002.

2. Aplique o manifesto ao cluster:

   kubectl apply -f my-mc-deployment.yaml
   

Crie um serviço

1. Guarde o seguinte manifesto como my-mc-service.yaml:

   apiVersion: v1
   kind: Service
   metadata:
     name: my-mc-service
   spec:
     type: NodePort
     selector:
       app: products
       department: sales
     ports:
     - name: my-first-port
       protocol: TCP
       port: 60001
       targetPort: 50001
     - name: my-second-port
       protocol: TCP
       port: 60002
       targetPort: 50002
   

   Este manifesto descreve um serviço com os seguintes campos:

   • selector: especifica que qualquer Pod que tenha a etiqueta app: products e a etiqueta department: sales é membro deste serviço.
   • ports: especifica que, quando um cliente envia um pedido ao serviço em my-first-port, o GKE encaminha o pedido para um dos pods membros na porta 50001. Quando um cliente envia um pedido para o Serviço em my-second-port, o GKE encaminha o pedido para um dos pods membros na porta 50002.

2. Aplique o manifesto ao cluster:

   kubectl apply -f my-mc-service.yaml
   

Crie certificados e chaves

Para fazer os exercícios nesta página, precisa de dois certificados, cada um com uma chave correspondente. Cada certificado tem de ter um nome comum (CN) igual a um nome de domínio que lhe pertence.

Pode criar esses certificados manualmente ou usar certificados geridos pela Google.

Se já tiver dois ficheiros de certificado com os valores adequados para o nome comum, pode avançar para a secção seguinte.

  apiVersion: networking.gke.io/v1
  kind: ManagedCertificate
  metadata:
    name: FIRST_CERT_NAME
  spec:
    domains:
      - FIRST_DOMAIN
  ---
  apiVersion: networking.gke.io/v1
  kind: ManagedCertificate
  metadata:
    name: SECOND_CERT_NAME
  spec:
    domains:
      - SECOND_DOMAIN

Especifique certificados para o seu Ingress

O passo seguinte é criar um objeto Ingress. No manifesto do Ingress, pode usar um dos seguintes métodos para fornecer certificados para o equilibrador de carga:

• Secrets
• Certificados pré-partilhados
• Certificados geridos pela Google

Teste o balanceador de carga

Aguarde cerca de cinco minutos para que o GKE termine a configuração do balanceador de carga.

Se usou certificados geridos pela Google, a conclusão da configuração pode demorar consideravelmente mais tempo, uma vez que o sistema tem de aprovisionar os certificados e validar a configuração de DNS para os domínios indicados.

Para testar o equilibrador de carga, tem de ter dois nomes de domínio e ambos os nomes de domínio têm de resolver o endereço IP externo do equilibrador de carga de aplicações externo.

1. Envie um pedido ao balanceador de carga através do seu primeiro nome de domínio:

   curl -v https://FIRST_DOMAIN
   

   Pode ter de usar a opção curl -k para fazer uma transferência SSL não segura, para que o curl aceite certificados autoassinados.

   O resultado é semelhante ao seguinte:

   ...
   *   Trying 203.0.113.1...
   ...
   * Connected to FIRST_DOMAIN (203.0.113.1) port 443 (#0)
   ...
   * TLSv1.2 (IN), TLS handshake, Certificate (11):
   ...
   * Server certificate:
   *  subject: CN=FIRST_DOMAIN
   ...
   > Host: FIRST_DOMAIN.com
   ...
   Hello, world!
   Version: 1.0.0
   ...
   

   Este resultado mostra que o seu primeiro certificado foi usado no handshake TLS.

2. Envie um pedido ao balanceador de carga através do segundo nome de domínio:

   curl -v https://SECOND_DOMAIN
   

   O resultado é semelhante ao seguinte:

   ...
   *   Trying 203.0.113.1...
   ...
   * Connected to SECOND_DOMAIN (203.0.113.1) port 443 (#0)
   ...
   * Server certificate:
   *  subject: CN=SECOND_DOMAIN
   ...
   > Host: SECOND_DOMAIN
   ...
   Hello, world!
   Version: 2.0.0
   

   Este resultado mostra que o seu segundo certificado foi usado na negociação de TLS.

O campo hosts de um objeto Ingress

Um IngressSpec tem um campo tls que é uma matriz de objetos IngressTLS. Cada objeto IngressTLS tem um campo hosts e um campo SecretName. No GKE, o campo hosts não é usado. O GKE lê o nome comum (CN) do certificado no segredo. Se o nome comum corresponder ao nome de domínio num pedido do cliente, o equilibrador de carga apresenta o certificado correspondente ao cliente.

Que certificado é apresentado?

O balanceador de carga escolhe um certificado de acordo com estas regras:

• Se os segredos e os certificados pré-partilhados estiverem listados no Ingress, os certificados pré-partilhados têm prioridade sobre os segredos. Por outras palavras, os segredos continuam a ser incluídos, mas os certificados pré-partilhados são apresentados primeiro.

• Se nenhum certificado tiver um nome comum (CN) que corresponda ao nome do domínio no pedido do cliente, o equilibrador de carga apresenta o certificado principal.

• Para os segredos listados no bloco tls, o certificado principal encontra-se no primeiro segredo da lista.

• Para os certificados partilhados previamente indicados na anotação ingress.gcp.kubernetes.io/pre-shared-cert, a ordem pela qual indica os certificados determina o certificado principal. O certificado principal, que é apresentado quando nenhum outro certificado corresponde ao pedido do cliente, é o primeiro certificado apresentado na anotação.

• Quando usa certificados geridos pela Google, todos os certificados listados na anotação networking.gke.io/managed-certificates são automaticamente ordenados alfabeticamente por nome. O certificado principal é o que aparece primeiro nesta lista alfabética. Para definir um certificado específico como o principal, tem de atribuir nomes aos objetos ManagedCertificate em conformidade para controlar a ordem de ordenação. Por exemplo, para tornar my-default-cert o principal em relação a another-cert, pode atribuir-lhes os nomes 0-my-default-cert e 1-another-cert.

Práticas recomendadas para a rotação de certificados

Se quiser rodar o conteúdo do seu segredo ou certificado pré-partilhado, seguem-se algumas práticas recomendadas:

• Crie um novo Secret ou um certificado pré-partilhado com um nome diferente que contenha os novos dados do certificado. Anexe este recurso (juntamente com o existente) ao seu Ingress através das instruções fornecidas anteriormente. Quando estiver satisfeito com as alterações, pode remover o certificado antigo do Ingress.
• Se não se importar de interromper o tráfego, pode remover o recurso antigo do Ingress, aprovisionar um novo recurso com o mesmo nome, mas conteúdos diferentes e, em seguida, voltar a anexá-lo ao Ingress.

Para evitar gerir a rotação de certificados, consulte o artigo Use certificados SSL geridos pela Google.

Resolução de problemas

A especificação de secrets inválidos ou inexistentes resulta num erro de evento do Kubernetes. Pode verificar os eventos do Kubernetes para um Ingress da seguinte forma:

kubectl describe ingress

O resultado é semelhante ao seguinte:

Name:             my-ingress
Namespace:        default
Address:          203.0.113.3
Default backend:  hello-server:8080 (10.8.0.3:8080)
TLS:
  my-faulty-Secret terminates
Rules:
  Host  Path  Backends
  ----  ----  --------
  *     *     my-service:443 (10.8.0.3:443)
Events:
   Error during sync: cannot get certs for Ingress default/my-ingress:
 Secret "my-faulty-ingress" has no 'tls.crt'

O que se segue?

• Leia a vista geral da rede do GKE.

• Saiba como configurar nomes de domínios com endereços IP estáticos.

• Saiba como usar certificados SSL geridos pela Google.

• Se tiver uma aplicação em execução em vários clusters do GKE em diferentes regiões, configure um Multi Cluster Ingress para encaminhar o tráfego para um cluster na região mais próxima do utilizador.