MCC - Exponer cluster de Kubernetes con Ingress

De MCC™ Wiki
Revisión del 03:00 10 sep 2024 de Malejo (discusión | contribs.)
(difs.) ← Revisión anterior | Revisión actual (difs.) | Revisión siguiente → (difs.)

Requerimientos

IP Variable por ISP:

Configurar un servicio **DDNS** en mi router Ej: **no-ip.com**, y además, crear un registro **CNAME** en el DNS de su dominio con el subdominio Ej: domus.maxiscomputers.com el cual apunte a su DDNS, en este caso Ej: maxiscomputers.dyndns.net.

IP Fija: Redirigir puertos a ingress.

Quiero adaptar mi clúster de Kubernetes para que haga proxy inverso y genere automáticamente un certificado SSL con **Let's Encrypt**. ¿Es esto posible, dado esta arquitectura de DDNS y CNAME entre el dominio final que va a usar el usuario vs el DDNS?

Descripción del Escenario

  • **DDNS con no-ip.com**: Utilizas un DDNS para gestionar los cambios de IP de tu router, con maxiscomputers.dyndns.net como dominio proporcionado.
  • **Subdominio personalizado**: domus.maxiscomputers.com es el subdominio, con un registro CNAME apuntando a maxiscomputers.dyndns.net.
  • **Let's Encrypt**: Usarás Let's Encrypt para generar certificados SSL para el subdominio domus.maxiscomputers.com.

Retos a Considerar

  • **Verificación de Let's Encrypt (HTTP-01)**: Let's Encrypt necesita verificar el control sobre tu dominio antes de emitir un certificado. Para la verificación HTTP-01, se comprobará un archivo expuesto en la ruta http://domus.maxiscomputers.com/.well-known/acme-challenge/ desde tu clúster.
  • **Actualización de IP**: Como tu IP cambia cada 24 horas, debes asegurarte de que el DDNS esté actualizado para que Let's Encrypt apunte a la IP correcta al hacer la verificación. No-ip.com se encarga de este aspecto.
  • **Certificado para CNAME**: A pesar de que el subdominio real apunta a un DDNS, Let's Encrypt validará el dominio domus.maxiscomputers.com para emitir el certificado.

Solución Propuesta

Usaremos **cert-manager** en el clúster de Kubernetes, junto con un Ingress Controller (como **NGINX** o **Traefik**) para manejar el tráfico HTTPS y solicitar automáticamente los certificados de Let's Encrypt. El Ingress Controller actuará como un proxy inverso para redirigir el tráfico, y cert-manager gestionará los certificados SSL.

Pre-requisto

Agregar el siguiente CRD al cluster:

Instalar los CRDs de cert-manager

Cuando instalas cert-manager con Helm, es importante que los CRDs también se instalen. Si no los instalaste previamente, puedes hacerlo de esta manera:

kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/v1.10.0/cert-manager.crds.yaml

Esto instalará las CRDs necesarias para que cert-manager pueda manejar recursos personalizados como ClusterIssuer.

Verificar la Instalación de cert-manager

Después de instalar los CRDs, verifica que cert-manager esté correctamente instalado y funcionando:

kubectl get pods --namespace cert-manager

Deberías ver los pods de cert-manager en ejecución.

Aplicar el ClusterIssuer

Una vez que los CRDs estén instalados y cert-manager esté corriendo correctamente, vuelve a aplicar el manifiesto del ClusterIssuer:

kubectl apply -f clusterissuer.yaml

Verifica que el ClusterIssuer se haya creado correctamente:

kubectl get clusterissuer

Si aparece en la lista, estará listo para usar con tus recursos de Ingress.

Pasos a Seguir

1. **Instalar cert-manager**

Cert-manager gestionará la obtención y renovación de los certificados SSL de Let's Encrypt automáticamente.


  1. Agrega el repositorio Helm de Jetstack
helm repo add jetstack https://charts.jetstack.io
  1. Instala cert-manager en tu clúster
helm install cert-manager jetstack/cert-manager   --namespace cert-manager --create-namespace   --version v1.10.0

2. **Crear un ClusterIssuer para Let's Encrypt**

Configura un ClusterIssuer para que cert-manager pueda solicitar certificados de Let's Encrypt usando la verificación HTTP-01.

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: admin@maxiscomputers.com  # Reemplaza con tu email
    privateKeySecretRef:
      name: letsencrypt-prod
    solvers:
    - http01:
        ingress:
          class: nginx

Aplica el ClusterIssuer:

kubectl apply -f clusterissuer.yaml

3. **Configurar el Ingress para tu Aplicación**

Suponiendo que tienes un servicio en el puerto 80 en Kubernetes, configuraremos un recurso Ingress para gestionar el proxy inverso y la solicitud del certificado SSL.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: k8s-maxiscomputers-ingress
  namespace: maxiscomputers
  annotations:
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
    nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
    nginx.ingress.kubernetes.io/rewrite-target: /
    kubernetes.io/ingress.class: "nginx"  # Asegúrate de usar la clase correcta
spec:
  rules:
  - host: domus.maxiscomputers.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: k8s-maxiscomputers
            port:
              number: 80
  tls:
  - hosts:
    - domus.maxiscomputers.com
    secretName: domus-tls

Aplica el Ingress:

kubectl apply -f ingress.yaml

4. **Verificar la Configuración de DDNS**

Asegúrate de que el dominio domus.maxiscomputers.com esté correctamente apuntando a maxiscomputers.dyndns.net, y que tu router actualice el DDNS automáticamente.

5. **Configurar Ingress Controller (NGINX)**

Si aún no tienes un Ingress Controller, puedes instalar NGINX con:

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm install ingress-nginx ingress-nginx/ingress-nginx   --namespace ingress-nginx --create-namespace

Renovación Automática del Certificado

Cert-manager se encargará de renovar el certificado antes de su vencimiento (por defecto, cuando falten 30 días).

Conclusión

Con esta configuración, **cert-manager** solicitará automáticamente un certificado SSL para tu dominio domus.maxiscomputers.com, a pesar de que uses un CNAME hacia un DDNS. El certificado se renovará automáticamente y el Ingress Controller (NGINX en este caso) gestionará el tráfico y la redirección a HTTPS.