Usar varios certificados SSL en el balanceo de carga HTTPS con Ingress

En esta página se explica cómo configurar varios certificados SSL para recursos Ingress en clústeres de Google Kubernetes Engine (GKE).

Información general

Si quieres aceptar solicitudes HTTPS de tus clientes, el balanceador de carga de aplicaciones debe tener un certificado para poder demostrar su identidad a tus clientes. El balanceador de carga también debe tener una clave privada para completar el handshake de HTTPS.

Cuando el balanceador de carga acepta una solicitud HTTPS de un cliente, el tráfico entre el cliente y el balanceador de carga se cifra mediante TLS. Sin embargo, el balanceador de carga finaliza el cifrado TLS y reenvía la solicitud sin cifrar a la aplicación. Cuando configuras un balanceador de carga de aplicaciones a través de Ingress, puedes configurar el balanceador de carga para que presente hasta 15 certificados TLS al cliente.

El balanceador de carga usa la indicación del nombre de servidor (SNI) para determinar qué certificado debe presentar al cliente en función del nombre de dominio del handshake de TLS. Si el cliente no usa SNI o si usa un nombre de dominio que no coincide con el nombre común (CN) de uno de los certificados, el balanceador de carga usará el primer certificado que aparezca en el recurso Ingress.

En el siguiente diagrama se muestra el balanceador de carga que envía tráfico a diferentes backends en función del nombre de dominio utilizado en la solicitud:

Puedes proporcionar a un balanceador de carga de aplicaciones certificados SSL mediante los siguientes métodos:

• Certificados SSL gestionados por Google Consulta la página de certificados gestionados para obtener información sobre cómo usarlos.

• Trusted Cloud by S3NS Certificado SSL que gestionas tú. El certificado SSL usa un certificado precompartido que subes a tu Trusted Cloud by S3NS proyecto.

• Secretos de Kubernetes. El secreto contiene un certificado y una clave que creas tú mismo. Añade el nombre del secreto al campo tls del archivo de manifiesto de Ingress.

Puedes usar más de un método en el mismo Ingress. Esto permite realizar migraciones sin tiempo de inactividad entre métodos.

Perspectiva general

A continuación, se muestra un resumen de los pasos que se describen en este documento:

1. Crea un despliegue.

2. Crea un servicio.

3. Crea dos archivos de certificado y dos archivos de clave, o dos objetos ManagedCertificate. Debes configurar estos certificados en el mismo proyecto y en el mismo espacio de nombres en el que se haya implementado el balanceador de carga.

4. Crea un Ingress que use secretos o certificados precompartidos. Cuando creas el Ingress, GKE crea y configura un balanceador de carga de aplicaciones.

5. Prueba el balanceador de carga de aplicación.

Antes de empezar

Antes de empezar, asegúrate de que has realizado las siguientes tareas:

• Habilita la API de Google Kubernetes Engine.
Habilitar la API de Google Kubernetes Engine
• Si quieres usar Google Cloud CLI para esta tarea, instálala y, a continuación, inicialízala. Si ya has instalado la gcloud CLI, obtén la versión más reciente ejecutando gcloud components update.

• Debes tener dos nombres de dominio. Los nombres de dominio no pueden tener más de 63 caracteres.
• Asegúrate de que tienes un clúster Autopilot o Standard. Para crear un clúster, consulta Crear un clúster de Autopilot.

Limitaciones

• Los certificados gestionados por Google solo se admiten con Ingress de GKE mediante el balanceador de carga de aplicaciones externo. Los certificados gestionados por Google no admiten controladores Ingress de terceros.

• En el caso de los balanceadores de carga de aplicaciones internos, debes inhabilitar HTTP en el manifiesto de Ingress. No es necesario para el balanceador de carga externo.

• No debes cambiar ni actualizar manualmente la configuración del balanceador de carga de aplicaciones. Esto significa que no debe editar ninguno de los componentes del balanceador de carga, incluidos los proxies de destino, los mapas de URLs y los servicios de backend. GKE sobrescribe los cambios que hagas.

Crear un despliegue

1. Guarda el siguiente archivo de manifiesto 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 manifiesto describe un Deployment con tres pods. Cada pod tiene dos contenedores. Un contenedor ejecuta hello-app:1.0 y escucha en el puerto TCP 50001. El otro contenedor ejecuta hello-app:2.0 y escucha en el puerto TCP 50002.

2. Aplica el manifiesto a tu clúster:

   kubectl apply -f my-mc-deployment.yaml
   

Crea un servicio

1. Guarda el siguiente archivo de manifiesto 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 manifiesto describe un servicio con los siguientes campos:

   • selector: especifica que cualquier pod que tenga la etiqueta app: products y la etiqueta department: sales es miembro de este servicio.
   • ports: especifica que, cuando un cliente envía una solicitud al servicio en my-first-port, GKE reenvía la solicitud a uno de los Pods miembros en el puerto 50001. Cuando un cliente envía una solicitud al servicio en my-second-port, GKE reenvía la solicitud a uno de los pods miembros en el puerto 50002.

2. Aplica el manifiesto a tu clúster:

   kubectl apply -f my-mc-service.yaml
   

Crear certificados y claves

Para hacer los ejercicios de esta página, necesitas dos certificados, cada uno con una clave correspondiente. Cada certificado debe tener un nombre común (CN) que sea igual a un nombre de dominio de tu propiedad.

Puedes crear esos certificados manualmente o usar certificados gestionados por Google.

Si ya tiene dos archivos de certificado con los valores adecuados para Nombre común, puede pasar a la siguiente sección.

  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

Especificar certificados para tu Ingress

El siguiente paso es crear un objeto Ingress. En el manifiesto de Ingress, puede usar uno de los siguientes métodos para proporcionar certificados al balanceador de carga:

• Secretos
• Certificados precompartidos
• Certificados gestionados por Google

Probar el balanceador de carga

Espera unos cinco minutos a que GKE termine de configurar el balanceador de carga.

Si has usado certificados gestionados por Google, puede que la configuración tarde bastante más en completarse, ya que el sistema tiene que aprovisionar los certificados y verificar la configuración de DNS de los dominios en cuestión.

Para probar el balanceador de carga, debes tener dos nombres de dominio y ambos deben resolver la dirección IP externa del balanceador de carga de aplicaciones externo.

1. Envía una solicitud al balanceador de carga mediante tu primer nombre de dominio:

   curl -v https://FIRST_DOMAIN
   

   Es posible que tengas que usar la opción curl -k para realizar una transferencia SSL no segura, de forma que curl acepte certificados autofirmados.

   El resultado debería ser similar al siguiente:

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

   En este resultado se muestra que tu primer certificado se ha usado en el handshake TLS.

2. Envía una solicitud al balanceador de carga mediante tu segundo nombre de dominio:

   curl -v https://SECOND_DOMAIN
   

   El resultado debería ser similar al siguiente:

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

   Esta salida muestra que tu segundo certificado se ha usado en el handshake de TLS.

El campo hosts de un objeto Ingress

Un objeto IngressSpec tiene un campo tls que es una matriz de objetos IngressTLS. Cada objeto IngressTLS tiene un campo hosts y un campo SecretName. En GKE, el campo hosts no se utiliza. GKE lee el nombre común (CN) del certificado en el secreto. Si el nombre común coincide con el nombre de dominio de una solicitud de cliente, el balanceador de carga presenta el certificado correspondiente al cliente.

¿Qué certificado se presenta?

El balanceador de carga elige un certificado según estas reglas:

• Si tanto los secretos como los certificados precompartidos se incluyen en el Ingress, los certificados precompartidos tienen prioridad sobre los secretos. Es decir, los secretos se siguen incluyendo, pero los certificados precompartidos se presentan primero.

• Si ningún certificado tiene un nombre común (CN) que coincida con el nombre de dominio de la solicitud del cliente, el balanceador de carga presenta el certificado principal.

• En el caso de los secretos que aparecen en el bloque tls, el certificado principal es el primer secreto de la lista.

• En el caso de los certificados precompartidos que se indican en la anotación ingress.gcp.kubernetes.io/pre-shared-cert, el orden en el que se enumeran los certificados determina el certificado principal. El certificado principal, que se presenta cuando ningún otro certificado coincide con la solicitud del cliente, es el primer certificado que aparece en la anotación.

• Cuando usas certificados gestionados por Google, todos los certificados que se indican en la anotación networking.gke.io/managed-certificates se ordenan automáticamente por nombre en orden alfabético. El certificado principal es el que aparece en primer lugar en esta lista alfabética. Para definir un certificado específico como principal, debes asignar nombres a tus objetos ManagedCertificate de forma que se controle el orden de clasificación. Por ejemplo, para que my-default-cert sea el principal en lugar de another-cert, puedes llamarlos 0-my-default-cert y 1-another-cert.

Prácticas recomendadas para la rotación de certificados

Si quieres rotar el contenido de tu secreto o certificado precompartido, te recomendamos que sigas estas prácticas:

• Crea un secreto o un certificado precompartido con otro nombre que contenga los nuevos datos del certificado. Adjunta este recurso (junto con el que ya tienes) a tu Ingress siguiendo las instrucciones que se han proporcionado anteriormente. Cuando estés conforme con los cambios, puedes quitar el certificado antiguo del Ingress.
• Si no te importa interrumpir el tráfico, puedes quitar el recurso antiguo del Ingress, aprovisionar un recurso nuevo con el mismo nombre, pero con contenido diferente, y, a continuación, volver a adjuntarlo al Ingress.

Para no tener que gestionar la rotación de certificados, consulta el artículo Usar certificados SSL gestionados por Google.

Solución de problemas

Si se especifican secretos no válidos o que no existen, se produce un error de evento de Kubernetes. Para consultar los eventos de Kubernetes de un Ingress, sigue estos pasos:

kubectl describe ingress

El resultado debería ser similar al siguiente:

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'

Siguientes pasos

• Consulta la información general sobre la red de GKE.

• Consulta cómo configurar nombres de dominio con direcciones IP estáticas.

• Consulta cómo usar certificados SSL gestionados por Google.

• Si tienes una aplicación que se ejecuta en varios clústeres de GKE en diferentes regiones, configura un Ingress multiclúster para dirigir el tráfico a un clúster de la región más cercana al usuario.