Asegura tu homelab Kubernetes con TLS de comodín y sin puertos abiertos

Los autoalojadores que ejecutan clústeres de Kubernetes a menudo enfrentan un dilema entre seguridad y conveniencia al configurar HTTPS. Una nueva guía técnica demuestra cómo usar k3s, Traefik y cert-manager para emitir certificados de comodín confiables mediante desafíos DNS-01, eliminando la necesidad de abrir puertos de entrada desde Internet público.

Qué pasó

El artículo describe un método para asegurar aplicaciones web internas en un entorno homelab sin depender de certificados autofirmados ni exponer la red a escáneres externos. Al aprovechar el protocolo de desafío DNS-01, los administradores pueden demostrar la propiedad del dominio a las autoridades de certificación como Let's Encrypt mediante llamadas API a su proveedor de DNS. Este enfoque permite que cada aplicación enrutada a través del clúster reciba automáticamente certificados HTTPS válidos y confiables para el navegador.

El proceso comienza verificando el controlador de ingreso Traefik predeterminado instalado por k3s. En lugar de editar directamente los manifiestos generados, la guía recomienda usar un recurso HelmChartConfig para modificar la configuración de Traefik, como forzar las redirecciones de HTTP a HTTPS. También señala que se deben evitar tutoriales antiguos que sugieren la instalación de ingress-nginx, ya que ese proyecto fue retirado en noviembre de 2025, con el fin del mantenimiento en marzo de 2026. Se aconseja a los usuarios de k3s migrar cualquier configuración existente a la clase nativa de Traefik.

A continuación, la guía detalla la instalación de cert-manager, una herramienta que automatiza la gestión y emisión de certificados TLS. Una vez instalado, los administradores configuran un ClusterIssuer que interactúa con su proveedor de DNS, como Cloudflare, utilizando tokens de API con alcance limitado en lugar de claves globales. El paso final implica solicitar un único certificado de comodín para el dominio interno, que Traefik sirve luego como predeterminado para todas las conexiones TLS no coincidentes, simplificando la configuración de las aplicaciones individuales.

Detalles clave

• Sin puertos abiertos requeridos: El desafío DNS-01 valida la propiedad del dominio mediante registros DNS, por lo que no se necesita tráfico entrante desde Internet para la emisión de certificados.
• Eficiencia de comodines: Un solo certificado para *.home.example.com cubre todas las aplicaciones internas, reduciendo la sobrecarga de gestión y limitando la exposición en los registros públicos de Certificate Transparency.
• Configuración de Traefik: La configuración debe aplicarse mediante HelmChartConfig en el espacio de nombres kube-system, usando service.spec.type en lugar de la clave obsoleta service.type.
• Mejores prácticas de seguridad: Usa tokens de API con alcance limitado para proveedores de DNS y almacena secretos en el espacio de nombres cert-manager, no en los espacios de nombres de las aplicaciones.
• Prueba en staging primero: Prueba siempre la configuración del emisor con los servidores de staging de Let's Encrypt para evitar alcanzar los límites de tasa antes de cambiar a producción.
• Resolución interna: Los nombres de host internos resuelven solo mediante sobrescrituras de DNS LAN, asegurando que los servicios permanezcan inalcanzables desde fuera de la red local incluso si el dominio es público.

Antecedentes

La configuración tradicional de HTTPS para home labs a menudo involucra dos caminos problemáticos. Uno es usar certificados autofirmados, que generan advertencias del navegador y rompen los gestores de contraseñas, condicionando a los usuarios a ignorar las alertas de seguridad. El otro es abrir el puerto 80 para permitir desafíos HTTP-01, lo que expone la red interna a posibles ataques. El desafío DNS-01 resuelve esto permitiendo que la autoridad de certificación verifique el control de un dominio comprobando un registro TXT específico en la zona DNS, un proceso que ocurre completamente fuera de banda del servidor web.

En Kubernetes, un controlador de ingreso actúa como punto de entrada para el tráfico externo, enrutando solicitudes a los servicios apropiados. Traefik, incluido con k3s, maneja este enrutamiento y la terminación TLS. Al establecer un almacén TLS predeterminado en Traefik, los administradores pueden garantizar que cualquier solicitud que coincida con el dominio interno reciba el certificado de comodín correcto sin necesidad de especificar referencias de secretos en cada recurso Ingress individual. Esto desacopla la gestión de certificados del despliegue de aplicaciones.

Por qué importa

Para equipos e individuos que gestionan infraestructura autoalojada, mantener la confianza en las herramientas internas es crítico. Las advertencias del navegador erosionan la confianza del usuario y crean puntos ciegos de seguridad donde los ataques de phishing podrían tener éxito porque los usuarios están acostumbrados a omitir errores de certificado. Automatizar la emisión de certificados válidos asegura que los paneles internos, entornos de desarrollo y herramientas administrativas se comporten exactamente como sistemas de producción, fomentando mejores hábitos de higiene de seguridad.

Además, reducir la superficie de ataque es una preocupación principal para cualquier líder de TI. Al evitar reenvíos de puertos para la validación de certificados, el homelab permanece invisible para escáneres a nivel de Internet. Esta configuración se alinea con los principios de confianza cero (zero-trust) donde el acceso se otorga mediante VPNs en lugar de reglas de firewall abiertas. También simplifica las operaciones; agregar un nuevo servicio requiere solo una definición estándar de Ingress, con TLS manejado globalmente por el certificado de comodín.

El retiro de ingress-nginx también destaca la importancia de mantenerse actualizado con los cambios del ecosistema. Confiar en componentes nativos soportados como Traefik en k3s reduce la deuda técnica y asegura continuas actualizaciones de seguridad. Este enfoque proporciona una base robusta y mantenible para servicios internos que escala a medida que se agregan más aplicaciones al clúster.

Qué puedes hacer

• Verifica tu versión de Traefik en k3s y actualiza la configuración usando HelmChartConfig para forzar redirecciones HTTPS.
• Instala cert-manager con CRDs habilitadas y configura un ClusterIssuer para tu proveedor de DNS usando tokens de API con alcance limitado.
• Solicita un certificado de comodín para tu dominio interno usando primero el emisor de staging para validar el proceso de desafío DNS.
• Configura un TLSStore de Traefik para establecer el certificado de comodín como predeterminado para todas las conexiones TLS entrantes.
• Asegúrate de que el DNS interno resuelva tu dominio privado a la IP del LoadBalancer de Traefik, manteniendo los servicios inaccesibles desde Internet público.
• Reemplaza cualquier configuración restante de ingress-nginx con recursos Ingress compatibles con Traefik, eliminando anotaciones obsoletas.