Ir al contenido principal

TLS Bootstrapping en Kubernetes: Qué es, cómo funciona y por qué importa en el examen CKA

                                           

Uno de los conceptos que a menudo pasan desapercibidos en la administración de Kubernetes —pero que resultan clave tanto en entornos reales como en el examen CKA— es el TLS Bootstrapping.

En este artículo entenderás qué es, cómo funciona, qué lo diferencia del kubeadm join tradicional y cómo puede aparecer en el examen.

¿Qué es TLS Bootstrapping?

TLS Bootstrapping es el proceso por el cual el kubelet, el agente que corre en cada nodo, obtiene automáticamente un certificado TLS firmado por el clúster para autenticarse con el kube-apiserver.

En otras palabras: permite que un nuevo nodo se una de forma segura al clúster sin necesidad de copiar manualmente los certificados.

¿Por qué es necesario?

Cuando añades un nuevo nodo worker, su kubelet necesita autenticarse para:

  • Recibir pods

  • Informar su estado

  • Acceder a ciertos recursos del clúster

Para ello, debe poseer un certificado TLS válido. TLS Bootstrapping automatiza este proceso, eliminando la necesidad de que el administrador copie certificados manualmente.

 ¿Cómo funciona TLS Bootstrapping?

  1. 🔑 El administrador genera un token con kubeadm token create

  2. 🧩 El nodo worker arranca con ese token en su configuración provisional

  3. 📬 El kubelet envía una solicitud CSR (Certificate Signing Request) al API Server

  4. ✅ La CSR es aprobada automáticamente o por un administrador

  5. 📜 El kubelet guarda su certificado firmado y comienza a autenticarse con él

 ¿Cuál es la diferencia con kubeadm join?


Cuando usas kubeadm join, TLS Bootstrapping ya está ocurriendo internamente. Pero si en el examen te piden "Configura TLS Bootstrapping sin usar kubeadm join", necesitas crear el token, configurar RBAC y aprobar la CSR tú mismo

Componentes involucrados:


Archivos implicados

Una vez aprobado el certificado, el kubelet guarda:

/var/lib/kubelet/pki/kubelet-client-current.pem

El token ya no es necesario después de la autenticación inicial.


 ¿Cómo saber si TLS Bootstrapping está en uso?

kubectl get csr

Verás las solicitudes de certificados de los kubelet pendientes o ya aprobadas

¿Cómo puede aparecer en el examen CKA?

  1. Pregunta genérica:

    “Une un nuevo nodo al clúster usando kubeadm”

    • Solo ejecutas kubeadm token create --print-join-command en el master y lo pegas en el worker

    • TLS Bootstrapping ocurre implícitamente

  2. Pregunta avanzada:

    “Configura manualmente TLS Bootstrapping para unir un nodo al clúster. No uses kubeadm join.”

    • Aquí debes usar el token y configurar el kubelet manualmente

    • Deberás revisar CSR y aprobarlos si no se aprueban automáticamente

¿Y qué ocurre si uso directamente kubeadm join? Saltándome los pasos anteriores:

Una duda frecuente es: ¿tengo que generar el token y el ClusterRoleBinding manualmente? Y la respuesta corta es: No, si estás usando kubeadm.

Cuando ejecutas kubeadm init en el nodo controlplane, se crean automáticamente:

  • Un token válido para unión de nodos
  • El ClusterRoleBinding para permitir a los kubelets pedir certificados
  • La configuración del API Server para aceptar CSR de nuevos nodos

Por eso, cuando en el nodo worker lanzas simplemente:

kubeadm join <IP_API_SERVER>:6443 --token <TOKEN> --discovery-token-ca-cert-hash sha256:<HASH>

👉 Se realiza todo el TLS Bootstrapping de forma automática:

  • El kubelet envía su CSR al API Server
  • La CSR es aprobada automáticamente
  • El nodo aparece en el clúster en estado Ready

✔️ ¿Cuál de los dos métodos debería usar?

Método Cuándo usarlo Ventajas Limitaciones
kubeadm join (automático) 90% de los casos reales y prácticos Fácil, rápido, seguro, usado en producción No aprendes los detalles internos del bootstrapping
TLS Bootstrapping manual Preguntas avanzadas del examen o clúster sin kubeadm Aprendes el flujo completo: CSR, RBAC, aprobación Más pasos, más propenso a errores

🔑 Recomendación: Para entornos reales y simulaciones básicas, kubeadm join es la vía rápida y correcta.
Pero para el examen CKA, debes entender el TLS Bootstrapping manual y practicar cómo hacerlo sin depender del automatismo de kubeadm.


Entender TLS Bootstrapping te da un conocimiento profundo sobre cómo Kubernetes gestiona la autenticación segura de los nodos. Aunque kubeadm join lo automatiza, conocer su funcionamiento interno te prepara para escenarios más avanzados y preguntas técnicas del examen CKA.

📎 En el próximo artículo te mostramos cómo hacer TLS Bootstrapping paso a paso, incluyendo un ejemplo práctico.

👉 Ir al ejercicio práctico sobre TLS Bootstrapping

Comentarios

Entradas populares de este blog

Ubicación, Estructura y Manejo básico de certificados.

                                                     Kubernetes utiliza certificados TLS (X.509) para cifrar la comunicación entre sus componentes y autenticar identidades (usuarios, nodos, API Server, etc.). Estos certificados son generados y gestionados automáticamente cuando se instala un clúster con kubeadm . En este artículo, veremos dónde se almacenan los certificados , cuál es su estructura y cómo inspeccionarlos fácilmente, una habilidad muy útil para el examen CKA. Cuando creas un clúster con kubeadm , los certificados se generan por defecto en el directorio: /etc/ kubernetes /pki/ Puedes ver su contenido con: ls -l /etc/kubernetes/pki/ También hay certificados en: /etc/kubernetes/ (ahí verás admin.conf , kubelet.conf , etc., que incluyen certificados embebidos, como veremos más abajo). 🧱 Estructura de los ce...

🔁 Renovación y Rotación de Certificados en Kubernetes (kubeadm certs)

  🎯 Introducción En un clúster de Kubernetes, la mayoría de los certificados generados por kubeadm tienen una validez de un año . Para evitar interrupciones en los componentes críticos, es fundamental revisar periódicamente su vigencia y saber cómo renovarlos correctamente. En este artículo aprenderás: Cómo comprobar la expiración de los certificados Cómo renovarlos automáticamente con kubeadm Cómo simular una renovación manual con openssl Cómo aplicar los cambios reiniciando los componentes afectados 🕵️‍♂️ Comprobación del estado de los certificados Kubernetes ofrece una herramienta integrada para revisar los certificados del clúster: kubeadm certs check-expiration Este comando muestra información clave: Fecha de expiración Tipo de certificado Ruta en el sistema 📌 Salida de ejemplo: CERTIFICATE EXPIRES RESIDUAL TIME CERTIFICATE AUTHORITY apiserver Jan 06 , 2026 19 :56 UTC 330d ...