Cert-Manager Kubernetes: Certificados TLS en 7 Pasos 2026

Cert-Manager Kubernetes automatiza la emisión y renovación de certificados TLS en clústeres: integra Let’s Encrypt, CA privadas y protocolos ACME para que tus Ingress y servicios expongan HTTPS sin intervención manual. En esta guía instalamos cert-manager con Helm, creamos un ClusterIssuer y protegemos un host de ejemplo con un recurso Certificate.

• Objetivo: TLS automático alineado con buenas prácticas GitOps.
• Requisitos: cluster operativo, Helm 3 y DNS que apunte a tu balanceador.

¿Qué es Cert-Manager Kubernetes?

Cert-Manager Kubernetes es el operador de facto para gestionar el ciclo de vida de certificados X.509 dentro del clúster. Observa recursos personalizados como Certificate, CertificateRequest y ClusterIssuer, negocia con ACME y almacena secretos compatibles con Ingress NGINX, Traefik u otros controladores. La documentación oficial está en cert-manager.io y el código en GitHub cert-manager.

Si ya despliegas charts con Helm Kubernetes o aplicas políticas con Kyverno Kubernetes, Cert-Manager Kubernetes encaja como capa transversal antes de endurecer red con Cilium Kubernetes. Para backups del plano de control revisa Velero Kubernetes y sincroniza secretos con External Secrets Operator Kubernetes.

Instalar Cert-Manager Kubernetes con Helm

Añade el repositorio y instala la versión estable acorde a la matriz de compatibilidad del proyecto:

helm repo add jetstack https://charts.jetstack.io --force-update
helm upgrade --install cert-manager jetstack/cert-manager \
  --namespace cert-manager --create-namespace \
  --set installCRDs=true

Verifica que los pods cert-manager, cainjector y webhook estén Running. En entornos productivos fija resources y podDisruptionBudgets según tu política SRE; el chart expone valores para afinar seguridad y HA. Consulta las notas de la release en GitHub antes de saltar de versión mayor.

Cert-Manager Kubernetes: ClusterIssuer con Let’s Encrypt

Define un emisor de clúster apuntando al entorno de staging primero para evitar rate limits, luego promociona a producción:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: [email protected]
    privateKeySecretRef:
      name: letsencrypt-prod-account-key
    solvers:
    - http01:
        ingress:
          class: nginx

El bloque http01 asume que tu controlador de Ingress expone el desafío en el puerto 80. Si usas DNS-01 (por ejemplo para wildcard), configura el solver con tu proveedor DNS y credenciales en un Secret. Cert-Manager Kubernetes creará los recursos temporales necesarios y limpiará tras la validación.

En clusters gestionados (EKS, GKE, AKS) revisa cómo el balanceador expone el puerto 80/443 hacia el servicio del controlador de Ingress: un Security Group demasiado restrictivo o un health check fallido impedirá el desafío HTTP-01 aunque el pod esté sano. Para certificados internos (*.svc.cluster.local) usa una CA privada o un Issuer por namespace con políticas estrictas; no intentes Let’s Encrypt en nombres no públicos.

Los equipos con múltiples zonas DNS deben asegurarse de que el proveedor configurado en el solver sea el autoritativo que responde en Internet; delegaciones parciales mal configuradas provocan errores “NXDOMAIN” difíciles de diagnosticar si solo miras logs del pod. Documenta el flujo end-to-end: usuario crea Certificate → cert-manager crea Order → ACME valida → Secret TLS disponible para el Ingress.

Cert-Manager Kubernetes: recurso Certificate

Crea un manifiesto que referencie el ClusterIssuer y el host deseado:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: demo-tls
  namespace: default
spec:
  secretName: demo-tls-secret
  issuerRef:
    kind: ClusterIssuer
    name: letsencrypt-prod
  dnsNames:
  - app.tudominio.com

Asocia el Secret generado a tu Ingress (campo tls) o deja que el controlador lo detecte mediante anotaciones compatibles. Revisa eventos con kubectl describe certificate demo-tls si el estado no avanza a Ready. En muchos equipos GitOps, este manifiesto vive junto al chart de la aplicación para mantener visibilidad end-to-end.

Cert-Manager Kubernetes: renovación y alertas

Cert-manager renueva antes del vencimiento, pero debes monitorizar fallos de ACME o cuotas DNS. Integra métricas Prometheus (ServiceMonitor) y alertas en Alertmanager; si usas stack Prometheus del blog, enlaza con Prometheus Kubernetes. Documenta también el procedimiento de revocación si una clave queda expuesta.

Configura alertas para CertificateReady=False más de N minutos y para órdenes ACME rechazadas. En entornos multi-cluster, replica la configuración de issuers mediante plantillas Kustomize o Helm umbrella para evitar desviaciones. Los equipos que despliegan con ArgoCD Kubernetes suelen versionar ClusterIssuer y Certificate en el mismo repositorio que la app, de modo que un rollback de release también revierta TLS si fuera necesario.

La documentación de Kubernetes sobre Ingress sigue siendo la referencia para entender cómo el tráfico llega al desafío HTTP-01; si cambias de Ingress NGINX a Gateway API, revisa las notas de compatibilidad del chart de Cert-Manager Kubernetes para tu versión.

Para clusters multi-tenant, separa Issuer por namespace y restringe RBAC: solo equipos autorizados deben crear Certificate con dominios corporativos. Esta gobernanza refuerza que Cert-Manager Kubernetes no sea una vía para obtener certificados no auditados.

Cert-Manager Kubernetes: seguridad y límites

Protege el webhook de admisión y el controlador con NetworkPolicies que permitan solo el plano de control y los Ingress necesarios. Rota credenciales DNS y evita almacenar tokens en ConfigMaps. Si necesitas mTLS interno, combina cert-manager con una CA intermedia alojada en Vault o en un CA Issuer dedicado. Los equipos regulados deben registrar el flujo ACME en el inventario de cifrado y asociar responsables de dominio.

Cert-Manager Kubernetes: GitOps y revisiones

Versionar manifiestos de Cert-Manager Kubernetes permite auditar quién solicitó un dominio nuevo y cuándo. Añade validaciones en CI (kubeconform, kyverno) para impedir dnsNames fuera de los sufijos corporativos. Los equipos de plataforma pueden exponer plantillas golden: un Certificate estándar con duración corta y algoritmos modernos (RSA 2048+ o ECDSA) según política interna.

En upgrades del operador, lee las notas de migración: a veces cambian versiones de API o comportamiento del webhook. Programa ventanas de mantenimiento y prueba en staging con el mismo volumen de namespaces que producción. Documenta dependencias con otros operadores (service mesh, API gateways) para evitar carreras al reiniciar webhooks.

Cert-Manager Kubernetes: troubleshooting

Errores frecuentes: DNS que no resuelve al balanceador, puerto 80 bloqueado, issuer staging mezclado con secretos prod, o cuotas Let’s Encrypt excedidas. Usa cmctl (CLI oficial) para inspeccionar cadenas y estados. Cuando migras de un proveedor TLS anterior, rota secretos y valida que los Ingress no referencien certificados caducados en cache del cliente.

Si observas bucles de reemisión, revisa relojes del clúster (NTP) y la caducidad declarada frente a la emitida. Para DNS-01, confirma propagación TXT con herramientas externas antes de abrir un ticket al proveedor cloud. Los logs del pod cert-manager suelen incluir el detalle ACME devuelto por Let’s Encrypt; conserva esos extractos al escalar incidencias con el equipo de red.

Cert-Manager Kubernetes: observabilidad y costes

Exporta métricas de órdenes ACME exitosas y fallidas, latencia de emisión y tiempo restante hasta la renovación. Correlaciónalas con eventos del plano de control para detectar picos tras despliegues masivos de Ingress. Aunque Let’s Encrypt no cobra, sí existen límites: monitorizar evita quedarte sin capacidad de emitir certificados el día del lanzamiento.

En clusters híbridos, etiqueta namespaces con el equipo dueño del dominio para facturar internamente el esfuerzo de soporte TLS. Integra dashboards en Grafana u otras herramientas ya desplegadas; lo importante es que negocio y plataforma vean el mismo semáforo cuando un certificado está a punto de caducar.

FAQ sobre Cert-Manager Kubernetes

¿Soporta wildcard? Sí, con DNS-01 y credenciales del proveedor.

¿Puedo usar CA interna? Sí, mediante ClusterIssuer de tipo CA o Vault.

¿Compatibilidad con Gateway API? Cert-manager evoluciona con soporte experimental; revisa la documentación vigente para tu versión.

¿Cómo pruebo sin tocarme el límite de Let’s Encrypt? Usa el endpoint de staging y valida toda la cadena; solo entonces cambia el ClusterIssuer a producción.

¿Qué ocurre si borro un Certificate a mano? El Secret TLS puede quedar huérfano o regenerarse según políticas; usa GitOps para eliminar recursos en orden y evita downtime.

¿Necesito Istio/Linkerd? No para TLS perimetral; el mesh añade mTLS interno, ortogonal a lo que resuelve Cert-Manager Kubernetes con ACME.

¿Dónde aprendo más sobre almacenamiento seguro de claves? Consulta las guías de Secrets en Kubernetes y endurece RBAC en namespaces sensibles.

Conclusión: Cert-Manager Kubernetes

Cert-Manager Kubernetes es la pieza que convierte “HTTPS sí, pero más tarde” en un proceso automatizado y auditable. Instálalo con Helm, valida en staging, define issuers por entorno y monitoriza renovaciones. Así mantendrás alineados equipos de plataforma y aplicaciones sin sacrificar seguridad ni cumplimiento.

La madurez llega cuando los desarrolladores pueden solicitar certificados mediante PR sin tocar la consola del proveedor DNS, y cuando el equipo de seguridad dispone de trazas claras de emisión y revocación. Invierte tiempo en pruebas de caída del webhook y en simulacros de expiración masiva: el día que un incidente golpee, el runbook ya estará ensayado.

Finalmente, mantén un ojo en la hoja de ruta del proyecto: la comunidad incorpora mejoras continuas para Gateway API, SPIFFE y otras integraciones. Suscribirse a los anuncios oficiales y probar RC en entornos no productivos reduce sorpresas en upgrades mayores de Cert-Manager Kubernetes.