Configuración de SSL/TLS para Ingress en Kubernetes

Hoy en día, las aplicaciones web y móviles, así como los endpoints de microservicios basados en API, se están convirtiendo en la norma. Se puede acceder a estas aplicaciones mediante el protocolo web HTTP. El cifrado que proporciona Secure Sockets Layer o Transport Layer Security (SSL/TLS) es indispensable para proteger la comunicación entre el cliente y el servidor, así como entre los backends de las API.

SSL/TLS son mecanismos de cifrado basados en certificados. SSL ha sido el estándar durante más de 20 años. TLS es una evolución más segura de SSL: se basa en el mismo concepto, pero utiliza mecanismos de cifrado más estrictos.

Los certificados TLS pueden estar autofirmados por la autoridad certificadora interna de una organización o firmados por una de las muchas autoridades certificadoras públicas disponibles, como GoDaddy, DigiCert, Symantec, GlobalSign y Let’s Encrypt. Cuando se cifra la comunicación basada en IP, el tráfico queda protegido frente a atacantes que inspeccionan los paquetes de datos.

En un entorno de Kubernetes, los contenedores de las cargas de trabajo se ejecutan dentro de la red de Kubernetes. Por lo general, se exponen al mundo exterior (en línea) mediante un controlador Ingress basado en HTTP: un servicio basado en API que dirige el tráfico a los POD. Para garantizar la seguridad en este escenario, debemos agregar una configuración basada en cifrado SSL/TLS al clúster de Kubernetes.

Cualquier escenario común en el que se intercambien datos —por ejemplo, al enviar un nombre de usuario y una contraseña para autenticarse, leer datos confidenciales como claves de acceso a endpoints de aplicaciones y almacenamiento, cadenas de conexión a bases de datos y similares— siempre se beneficia del cifrado.

Este artículo muestra cómo configurar certificados TLS/SSL con el controlador Ingress de Kubernetes. Configuraremos un controlador NGINX Ingress, crearemos un certificado SSL/TLS autofirmado, crearemos las reglas necesarias para vincular el certificado SSL/TLS con el controlador y lo conectaremos a un servicio de aplicación de ejemplo de Kubernetes.

Configuración de certificados TLS/SSL

Antes de comenzar, asegúrate de tener un entorno de Kubernetes en ejecución en tu máquina local (por ejemplo, Docker con Kubernetes o MiniKube) o en un entorno de nube alojado, como Azure (AKS), AWS (EKS), GCP (GKS) u Ocean (DOKS), con Helm instalado.

Esta demostración utiliza una implementación predeterminada de Azure Kubernetes Service, como se muestra en este artículo de Microsoft Learn, con una suscripción gratuita de Azure. Sin embargo, la mayoría de los pasos son específicos de Kubernetes, no de la nube, así que puedes seguirlos independientemente del entorno de alojamiento de Kubernetes que uses.

Creación del controlador Ingress

Comencemos insertando la configuración del controlador Ingress en el clúster de Kubernetes. Hay varias opciones disponibles, como NGINX, Google Cloud Load Balancer, Traefik y Contour. En este artículo usamos NGINX, un controlador Ingress conocido y relativamente sencillo de configurar. La comunidad de Kubernetes lo ofrece en GitHub a través de ingress-nginx.  

Además de los distintos controladores Ingress, hay varios métodos para configurarlos, como Helm o kubectl. Para esta demostración, usaremos Helm, ya que funciona con cualquier arquitectura de Kubernetes.

La implementación implica realizar los siguientes pasos:

• Especificar el nombre de un nuevo espacio de nombres de Kubernetes que utilizará el controlador Ingress. Para esto se usa la variable NAMESPACE.

• Descargar el paquete del controlador ingress-nginx mediante el comando helm repo add.

• Escribir la configuración que se actualizará mediante helm repo update.

• Ejecutar la instalación del paquete con el comando helm install.

Como este ejemplo utiliza Azure y Azure Load Balancer, el comando helm install se amplía para definir una integración con las sondas de estado de Azure Load Balancer. Esta configuración variará según tu entorno de Kubernetes (local, Azure, AWS, GCP, etc.).

En la línea de comandos, ejecuta lo siguiente:

1NAMESPACE=ingress-nginx
2
3helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
4helm repo update
5
6helm install ingress-nginx ingress-nginx/ingress-nginx \
7  --create-namespace \
8  --namespace $NAMESPACE \
9  --set controller.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-health-probe-request-path"=/healthz

La imagen de abajo muestra el comando helm completo:

El resultado de crear el controlador NGINX será similar al que se muestra en la imagen de abajo:

A continuación, valida la instalación del controlador Ingress con el siguiente comando:

1kubectl --namespace ingress-nginx get services -o wide -w ingress-nginx-controller

La imagen de abajo muestra la respuesta al comando anterior.

En tu navegador, conéctate a la EXTERNAL-IP indicada para ingress-nginxcontroller. Todavía no especificamos ninguna regla de Ingress porque aún no dirigimos el tráfico a un servicio de aplicación real, lo que dará como resultado un error HTTP 404. Sin embargo, puedes ver que el controlador NGINX está respondiendo.

Ten en cuenta que, en una Mac, la IP externa puede aparecer como localhost en lugar de un número IP.

Al hacer clic en el mensaje No seguro, verás que no se está usando ningún certificado:

Ahora, intenta conectarte de nuevo a la misma dirección IP. Esta vez, usa HTTPS. Aparecerá una advertencia del navegador que te indicará que no es seguro continuar, como se muestra abajo:

Haz clic en el botón Avanzado y luego en Continuar a .

En la misma pestaña No seguro, haz clic en el ícono del certificado que se resalta abajo:

Esto muestra los detalles del certificado ficticio integrado del controlador Ingress, como se muestra abajo. Este es el certificado que vamos a reemplazar.

Selección de un certificado SSL/TLS

Los certificados SSL/TLS se pueden obtener de varias maneras:

• Autofirmado: Este tipo de certificado suele usarse para fines internos y se basa en la autoridad certificadora (CA) de tu propia infraestructura de clave pública (PKI).

• Adquirido de una autoridad certificadora pública: Se usa principalmente para aplicaciones accesibles desde Internet. Las organizaciones compran un certificado SSL/TLS a una autoridad certificadora pública, como GlobalSign, Symantec, DigiCert o GoDaddy. La principal ventaja de usar una CA pública es que los certificados raíz, que validan todos los certificados emitidos, son de confianza para los navegadores modernos. Por lo general, los certificados tienen una validez de uno a cinco años.

• Let’s Encrypt: Let’s Encrypt es un proyecto sin fines de lucro. La principal diferencia entre las CA públicas y Let’s Encrypt es que no tienes que pagar por los certificados SSL/TLS. Además, los certificados de Let’s Encrypt solo tienen una validez de tres meses.

Además del tipo de certificado SSL/TLS, debemos considerar las tareas de mantenimiento, como la rotación de certificados y claves. Para el caso de uso de Kubernetes y el controlador Ingress de este artículo, algunas opciones son ejecutar tareas programadas para crear un nuevo certificado SSL/TLS y trabajos cron en el clúster de Kubernetes para crear nuevos Secrets. También es importante elegir una vigencia adecuada para los certificados de tu CA pública o de Let’s Encrypt.

Otro aspecto del cifrado y la seguridad SSL/TLS es decidir si quieres implementar el cifrado en el nivel del controlador Ingress, en el nivel del Pod o de la aplicación, o en ambos. Cada escenario tiene ventajas y desventajas. El cifrado en el nivel de Ingress te permite establecer un vínculo directo entre todas las solicitudes entrantes de Ingress y los servicios de backend de Kubernetes.

Almacenar certificados SSL/TLS dentro del Pod o la aplicación en ejecución agrega complejidad. Sin embargo, puede haber razones de negocio para garantizar el cifrado del tráfico entre el controlador Ingress y el Pod o la aplicación, además del tráfico cifrado hacia Internet que establece la configuración del controlador. Para esta demostración, crearemos un certificado autofirmado. Sin embargo, los pasos son similares para las otras dos opciones.

Desde una máquina Mac o Linux, o desde la terminal de una plataforma en la nube (en este caso, Cloud Shell), ejecuta el siguiente comando openssl:

1mkdir certs
2
3openssl req -x509 -nodes -days 9999 -newkey rsa:2048 -keyout certs/ingress-tls.key -out certs/ingress-tls.crt

La imagen de abajo muestra el resultado del comando anterior.

Ingresa la información de la organización que se incluirá en la solicitud del certificado, como el nombre de la organización, el código de país, la ubicación y la dirección de correo electrónico. Ten en cuenta que, en esta demostración, se usa www.ingress-tls.com como nombre de dominio completo (FQDN) del certificado.

Esto crea el archivo del certificado (CRT-extension) y el archivo de la clave privada del certificado (KEY-extension) en la carpeta \certs.

Creación del Secret de Kubernetes

A continuación, debemos vincular el certificado y la clave a un Secret de Kubernetes. Para ello, ejecuta el siguiente comando:

1kubectl create secret tls ingress-cert --namespace dev --key=certs/ingress-tls.key --cert=certs/ingress-tls.crt -o yaml

Puedes obtener el Secret con kubectl get secret. El resultado será similar al de la siguiente imagen:

Publicación de una nueva aplicación de ejemplo en el espacio de nombres de Ingress

A continuación, crea un nuevo archivo sample-app.yaml con la siguiente sintaxis (presta atención a los niveles de sangría de YAML):

1apiVersion: apps/v1
2kind: Deployment
3metadata:
4  name: sample-app
5  namespace: default
6spec:
7  selector:
8    matchLabels:
9      app: sample
10  replicas: 2
11  template:
12    metadata:
13      labels:
14        app: sample
15    spec:
16      containers:
17      - name: sample
18        image: "gcr.io/google-samples/hello-app:2.0"
19
20---
21
22apiVersion: v1
23kind: Service
24metadata:
25  name: sample-app-service
26  namespace: default
27  labels:
28    app: sample
29spec:
30  type: ClusterIP
31  selector:
32    app: sample
33  ports:
34  - port: 80
35    targetPort: 8080
36    protocol: TCP

Esto crea un nuevo servicio y una aplicación de ejemplo (que usa la imagen de contenedor de ejemplo hello-app de Google) dentro del espacio de nombres ingress-nginx existente. Ten en cuenta que el código asigna el Secret SSL/TLS a este espacio de nombres, por lo que solo puedes usarlo para las aplicaciones y los servicios que se ejecuten allí.

A continuación, inserta la configuración en el clúster de Kubernetes ejecutando el siguiente comando:

1kubectl apply -f sample-app.yaml:

Creación de la integración SSL/TLS entre el controlador Ingress y la aplicación de ejemplo

Por último, crea otro archivo llamado sample-ingress.yaml y declara el recurso Ingress con los siguientes parámetros de configuración SSL/TLS:

1apiVersion: networking.k8s.io/v1
2kind: Ingress
3metadata:
4  name: sample-app-ingress
5  namespace: default
6spec:
7  ingressClassName: nginx
8  tls:
9  - hosts:
10    - www.ingress-tls.com
11    secretName: ingress-cert
12  rules:
13  - host: "www.ingress-tls.com"
14    http:
15      paths:
16        - pathType: Prefix
17          path: "/"
18          backend:
19            service:
20              name: sample-app-service
21              port:
22                number: 80

En el ejemplo anterior, estos son los parámetros específicos que aplican SSL/TLS y lo asocian con el Secret:

1tls:
2  - hosts:
3    - www.ingress-tls.com
4    secretName: ingress-cert
5  rules:
6  - host: "www.ingress-tls.com"

La sección de rutas al final del archivo indica que todas las solicitudes entrantes al host se deben dirigir al sample-app-service creado en el paso anterior (la aplicación de contenedor hello-app de Google).

Vuelve a ejecutar el comando kubectl para aplicar esto al clúster de Kubernetes:

1kubectl apply -f sample-app-ingress.yaml

Para probar la conectividad con el FQDN, actualiza el archivo de hosts DNS de tu máquina local (normalmente /etc/hosts en una Mac o Linux, o C:\Windows\System32\Drivers\Etc\Hosts en Windows) para que la dirección IP del controlador Ingress apunte al FQDN utilizado.

Nota: si no quieres o no puedes actualizar el archivo de hosts local, puedes usar un servicio de resolución DNS como https://nip.io. Por ejemplo, el nombre de nuestro controlador Ingress se resolvería como 20.245.164.52.nip.io. Esta dirección se resolvería a la dirección IP del controlador20.245.164.52.

Abre el navegador y conéctate al FQDN que usaste para el certificado (www.ingress-tls.com o 20.245.164.52.nip.io en nuestro ejemplo). Ten en cuenta que seguirás viendo la advertencia «No es seguro» porque el navegador no confía en el certificado autofirmado. Haz clic en Avanzado y luego en Continuar para abrir la URL de la aplicación:

Como puedes ver, la aplicación de ejemplo (el saludo «Hello, world!» de la izquierda) funciona según lo previsto con el certificado SSL/TLS autofirmado que creamos antes.

Para obtener más información, consulta la herramienta CNCF Cert Manager. Ofrece una manera más avanzada de administrar certificados y crear Secrets automáticamente.

Comparación de distintos proveedores de Ingress

En esta guía paso a paso usamos el popular controlador NGINX Ingress, pero es solo uno de muchos controladores disponibles. Si recién comienzas a trabajar con Kubernetes, NGINX de código abierto es una solución sencilla para balancear la carga y proteger las cargas de trabajo de tu clúster. NGINX también ofrece una versión más orientada a empresas, llamada NGINX Plus. También podrías usar Kong, otra alternativa comercial que se basa en el mismo código que NGINX. Traefik es otra solución comercial que ofrece una amplia compatibilidad con protocolos, alta disponibilidad y otras funciones.

Cualquier solución que elijamos interactúa con la API de Ingress de Kubernetes. Sin embargo, a principios de este año, Kubernetes lanzó la versión beta de su Gateway API, que podría convertirse en una alternativa interesante a la API de Ingress actual, especialmente por sus funciones de control de acceso basado en roles granulares. Además de admitir varios protocolos estándar, como HTTP y TCP/UDP, una de las principales ventajas de Gateway API es que también incluirá compatibilidad integrada con TLS.

Como Gateway API se encuentra en una etapa inicial de desarrollo (actualmente está en versión beta), aún es pronto para saber qué futuro les espera a la API de Ingress y a Gateway API. Es posible que Gateway API, que se concibió como sucesora de la API de Ingress, ofrezca más funcionalidades que simplemente replicar las funciones de esta última. Pero por ahora se desconoce cómo se adaptarán otros proveedores y extensiones. La buena noticia es que la seguridad es una prioridad, y TLS se usa como estándar para el enrutamiento.

Conclusión

Los controladores de Ingress siempre forman parte del panorama cuando las cargas de trabajo y los servicios de Kubernetes están disponibles como aplicaciones accesibles desde Internet. Además de la funcionalidad de proxy inverso, se recomienda ampliamente integrar certificados SSL/TLS en tu arquitectura de Ingress. Esto garantiza el cifrado del tráfico entre el cliente (navegador) y el servidor (aplicación de Kubernetes Service). Kubernetes admite distintos proveedores de Ingress y acepta varios certificados SSL/TLS como Secrets. Consulta nuestra guía de seguridad de Kubernetes para conocer más prácticas recomendadas.

Con comandos administrativos estándar de Kubernetes, como Helm y kubectl, integrar SSL/TLS no debería ser más complicado que iniciar cualquier Kubernetes Service. También puedes consultar nuestra guía para implementar TLS/SSL en Python.

Proteger las comunicaciones entre el mundo exterior y tus aplicaciones con certificados SSL/TLS es solo un paso para ejecutar aplicaciones más seguras: también debes proteger cada etapa del ciclo de vida del desarrollo de software. Identifica y mitiga las posibles vulnerabilidades en el código que escribes y en los proyectos de código abierto que utilizas con Snyk Code y Snyk Open Source, y aprovecha Snyk Container para comenzar con una imagen base más segura e identificar las vulnerabilidades adicionales que puedas introducir durante el proceso de compilación. Por último, verifica con Snyk IaC que el código que implementas no incluya brechas de seguridad.