Certificados y autenticación en Kubernetes

En el capítulo anterior vimos que toda la comunicación del cluster va cifrada con TLS y firmada por la CA de /etc/kubernetes/pki/. Ahora toca gestionarla: entender qué certificado usa cada componente, comprobar caducidades, renovarlos y diagnosticar el clásico "certificado caducado" que deja el cluster inservible una mañana cualquiera.

La PKI del cluster, pieza a pieza

Un cluster de kubeadm mantiene, en realidad, tres CAs distintas:

CA	Ubicación	Firma
CA del cluster	/etc/kubernetes/pki/ca.crt	API server, kubelets, usuarios, kubeconfigs
CA de etcd	/etc/kubernetes/pki/etcd/ca.crt	Certificados de etcd y sus clientes
CA del front-proxy	/etc/kubernetes/pki/front-proxy-ca.crt	El agregador de APIs (extensiones como metrics-server)

Y cada componente se autentica con su propio certificado de cliente. Los kubeconfigs del control plane (/etc/kubernetes/*.conf: admin.conf, kubelet.conf, controller-manager.conf, scheduler.conf) llevan los certificados embebidos en base64.

Para inspeccionar cualquier certificado, openssl es tu herramienta:

# ¿Quién es, quién lo firma y cuándo caduca?
openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -subject -issuer -dates

# Ver los SANs (nombres alternativos) del API server, importante si cambias IPs o añades un balanceador
openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -ext subjectAltName

Caducidad y renovación con kubeadm

Los certificados que genera kubeadm duran 1 año (las CAs, 10). Si caducan, kubectl deja de funcionar con errores del tipo x509: certificate has expired. Es uno de los incidentes más comunes en clusters "olvidados".

kubeadm trae todo lo necesario para gestionarlo:

# Comprobar caducidades de todos los certificados
sudo kubeadm certs check-expiration

# Renovar todos los certificados
sudo kubeadm certs renew all

# O renovar uno concreto
sudo kubeadm certs renew apiserver

Tras renovar, hay que reiniciar los componentes del control plane para que carguen los certificados nuevos. Como son static pods, basta con moverlos temporalmente fuera del directorio de manifiestos o reiniciar el kubelet:

sudo systemctl restart kubelet

Y si renovaste admin.conf, recuerda actualizar tu copia local:

sudo cp /etc/kubernetes/admin.conf ~/.kube/config

Detalle importante: kubeadm upgrade renueva automáticamente todos los certificados. Si actualizas el cluster al menos una vez al año (deberías), nunca te caducarán.

Rotación del certificado del kubelet

Los kubelets rotan su certificado automáticamente si tienen rotateCertificates: true en su configuración (/var/lib/kubelet/config.yaml), que es el valor por defecto con kubeadm. Cuando les toca renovar, generan un CSR que el controller manager aprueba automáticamente.

La API CertificateSigningRequest

Ya la usamos para crear usuarios, pero es importante entender el flujo completo porque el examen CKA lo pide tal cual:

1. El solicitante genera su clave y su CSR con openssl:

openssl genrsa -out maria.key 2048
openssl req -new -key maria.key -out maria.csr -subj "/CN=maria/O=desarrollo"

2. Se crea el objeto CSR en Kubernetes (el campo request es el CSR en base64 sin saltos de línea):

apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: maria
spec:
  request: $(cat maria.csr | base64 | tr -d "\n")
  signerName: kubernetes.io/kube-apiserver-client
  expirationSeconds: 604800  # 7 días
  usages:
  - client auth

3. Un administrador lo revisa y aprueba (o deniega):

kubectl get csr
kubectl certificate approve maria
kubectl certificate deny maria   # Si algo no cuadra

4. Se extrae el certificado firmado y se construye el kubeconfig del usuario:

kubectl get csr maria -o jsonpath='{.status.certificate}' | base64 -d > maria.crt

kubectl config set-credentials maria --client-certificate=maria.crt --client-key=maria.key --embed-certs=true
kubectl config set-context maria@kubernetes --cluster=kubernetes --user=maria

5. Y se le dan permisos con RBAC, como vimos en el capítulo de roles. Sin el binding, maria se autentica pero no puede hacer nada.

Los signerName que debes reconocer: kubernetes.io/kube-apiserver-client (usuarios), kubernetes.io/kube-apiserver-client-kubelet (kubelets) y kubernetes.io/kubelet-serving (certificado de servidor del kubelet).

Diagnóstico de problemas de certificados

Síntomas y soluciones rápidas:

Síntoma	Causa probable	Solución
x509: certificate has expired	Certificados caducados	kubeadm certs renew all + reiniciar control plane
x509: certificate signed by unknown authority	kubeconfig con CA incorrecta (o cluster reinstalado)	Regenerar kubeconfig desde admin.conf
x509: certificate is valid for X, not Y	Accedes por una IP/nombre que no está en los SANs	Regenerar el certificado del API server añadiendo el SAN
Nodo NotReady tras meses apagado	Certificado del kubelet caducado sin rotar	Borrar /var/lib/kubelet/pki/* y reiniciar kubelet, o re-unir el nodo

Para añadir SANs al API server (por ejemplo, la IP de un nuevo balanceador), se edita la configuración de kubeadm (kubectl -n kube-system edit cm kubeadm-config, sección certSANs) y se regenera el certificado:

sudo rm /etc/kubernetes/pki/apiserver.{crt,key}
sudo kubeadm init phase certs apiserver --config kubeadm.yaml

Resumen

• kubeadm gestiona tres CAs; cada componente tiene su certificado de cliente, y los kubeconfigs del control plane los llevan embebidos.
• Los certificados duran 1 año: kubeadm certs check-expiration para auditar y kubeadm certs renew all para renovar. Las actualizaciones de cluster los renuevan solos.
• La API CSR permite firmar certificados de usuario desde el cluster: generar → aplicar → approve → extraer → RBAC.
• Ante errores x509, lee el mensaje completo: dice exactamente qué falla (caducidad, CA o SANs).

---

• Lista de vídeos en Youtube: Curso Kubernetes

Volver al índice