Diferencia entre revisiones de «MCC - Implementación Dockerizada»
Página creada con «Requisitos 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'''. == Requerimientos == 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…» |
Sin resumen de edición |
||
Línea 6: | Línea 6: | ||
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? | 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 === | === Descripción del Escenario === |
Revisión del 00:59 10 sep 2024
Requisitos 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.
Requerimientos
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.
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.
```bash
- Agrega el repositorio Helm de Jetstack
helm repo add jetstack https://charts.jetstack.io
- 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.
```yaml apiVersion: cert-manager.io/v1 kind: ClusterIssuer metadata:
name: letsencrypt-prod
spec:
acme: server: https://acme-v02.api.letsencrypt.org/directory email: <tu-email> # Reemplaza con tu email privateKeySecretRef: name: letsencrypt-prod solvers: - http01: ingress: class: nginx
```
Aplica el ClusterIssuer:
```bash 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.
```yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata:
name: domus-ingress namespace: default annotations: cert-manager.io/cluster-issuer: "letsencrypt-prod" nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
spec:
rules: - host: domus.maxiscomputers.com # El dominio para el que solicitas el certificado http: paths: - path: / pathType: Prefix backend: service: name: your-service-name # Cambia por el nombre de tu servicio port: number: 80 tls: - hosts: - domus.maxiscomputers.com secretName: domus-tls # Nombre del secreto que contendrá el certificado SSL
```
Aplica el Ingress:
```bash 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:
```bash 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.