PKI: la infraestructura de confianza que sostiene toda la seguridad en Kubernetes

La mayoría de los incidentes graves que he visto en clusters Kubernetes no empezaron siendo incidentes de PKI (Public Key Infrastructure). Empezaron siendo una expiración olvidada, una raíz generada hace años “para salir del paso”, un intermedio no distribuido a todos los nodos o un proceso de rotación que nadie había ensayado. Cuando se escarba, al fondo siempre hay una PKI mal diseñada sosteniendo demasiado peso. Este artículo forma parte de la serie La evolución de la seguridad en aplicaciones modernas.

Por qué la PKI sigue siendo el cimiento

PKI es el sistema que permite decir con fundamento criptográfico que una clave pública pertenece a una entidad concreta. Su valor no está en el cifrado, está en el vínculo verificable entre una identidad y un par de claves. Cada vez que un servidor presenta un certificado, cada vez que un pod autentica a otro con mTLS, cada vez que kubelet habla con kube-apiserver, y cada vez que un webhook firma una admisión, la decisión de confiar se reduce a una cadena que termina en una CA (Certificate Authority) que alguien decidió tratar como raíz de confianza.

La criptografía asimétrica moderna, formalizada en el perfil X.509 por RFC 5280, descansa en que la clave privada nunca sale de su titular y que la clave pública viaja dentro de un certificado firmado por una autoridad. Esa firma es lo que convierte un montón de bits en una afirmación verificable. El resto de la PKI (jerarquías, revocación, restricciones, políticas) es ingeniería alrededor de esa primitiva para que funcione a escala, bajo compromiso parcial, con rotación y con auditoría.

Mecánica de la validación

Construcción de la cadena y verificación

Cuando un cliente recibe un certificado no lo valida contra una CA concreta, valida un camino: construye una cadena que termine en algún certificado presente en su trust store. El proceso, descrito en RFC 5280 con un nivel de detalle quirúrgico, encadena certificados por el par issuer/subject, verifica la firma en cada eslabón, comprueba que ninguno ha expirado, que cada uno cubre el propósito declarado (servidor, cliente, firma de código) y que las restricciones de nombre y longitud de camino se respetan.

Lo que parece trivial esconde modos de fallo silenciosos. El cliente construye la cadena con los certificados que el servidor envía más los que tenga en su trust store o en cachés intermedias. Si el servidor olvida enviar el intermedio, algunos clientes lo reconstruyen por AIA (Authority Information Access) y otros fallan directamente. Esa asimetría entre runtimes explica por qué un servicio funciona desde Go y falla desde Java con exactamente el mismo certificado.

Revocación: CRL, OCSP y las costuras del sistema

Un certificado válido hoy puede estar comprometido mañana. El mecanismo histórico de revocación es la CRL (Certificate Revocation List), una lista firmada por la CA con los serial numbers revocados. El problema práctico es que las CRL crecen sin límite y su descarga completa es cara, lo que lleva a frecuencias de actualización incompatibles con contención rápida.

OCSP (Online Certificate Status Protocol) sustituye la lista por una consulta puntual: el cliente pregunta a un responder si un certificado concreto está revocado. Aparecen entonces dos problemas. El primero es la disponibilidad: si el responder cae, el cliente decide entre fallar cerrado (romper tráfico legítimo) o fallar abierto (aceptar certificados posiblemente revocados), y ambos son malos. El segundo es la privacidad: cada consulta OCSP revela al responder qué sitios visita el cliente. OCSP stapling resuelve ambos problemas haciendo que el servidor adjunte la respuesta OCSP firmada y vigente al handshake, eliminando el viaje extra y la fuga de metadatos, aunque introduce un requisito operativo: el servidor tiene que refrescar la respuesta antes de que expire.

En la práctica moderna, con certificados de corta duración emitidos por minutos u horas, la revocación deja de ser el mecanismo principal de contención. Si un certificado vive una hora, rotarlo es más barato que distribuir su revocación.

Jerarquías: por qué hay siempre más de una CA

Una PKI seria separa una Root CA de una o varias Intermediate CA. La raíz firma solo intermedios, vive offline la mayor parte del tiempo, protegida con HSM (Hardware Security Module) o equivalente, y su clave se utiliza en ceremonias raras y auditadas. Los intermedios firman los certificados de endpoint y sí están online porque tienen que responder al volumen operativo.

La jerarquía tiene dos ventajas concretas. La primera es la contención en caso de compromiso: si un intermedio se compromete, se revoca desde la raíz y se emite otro, sin tocar el trust store de los clientes. La segunda es la rotación ordenada: se puede introducir un nuevo intermedio en paralelo, rotar las cargas gradualmente y retirar el anterior cuando ya nadie lo usa.

La PKI dentro de Kubernetes

Los certificados que mantienen el cluster vivo

Kubernetes no es un sistema con PKI, es un sistema hecho de PKI. El kube-apiserver presenta un certificado firmado por la CA del cluster. Cada kubelet se autentica con un certificado de cliente. etcd, el corazón del estado, usa certificados separados para TLS de cliente, de peer y de servidor. Los service account tokens se firman con una clave propia que conceptualmente es parte de la misma infraestructura. Los webhooks de admisión aportan otro certificado firmado con la CA del cluster o con una específica configurada en el objeto de webhook.

La consecuencia operativa es que hay al menos cuatro o cinco autoridades distintas dentro de un cluster típico, cada una con su rotación, su trust store y sus consumidores. Distribuciones como kubeadm asumen por defecto ciertos caminos y ciertas duraciones (clásicamente un año para los certificados de endpoint), y la mayoría de incidentes de “el cluster no responde después del fin de semana largo” se explican por olvidar ese plazo.

Por qué cert-manager se ha convertido en inevitable

cert-manager ocupa hoy el hueco de “el operador que habla con cualquier emisor”. Abstrae la diferencia entre una emisión ACME contra Let’s Encrypt, una emisión contra Vault, contra una CA interna, contra HashiCorp Consul o contra un autofirmado solo para desarrollo. Sus CRD (Issuer, ClusterIssuer, Certificate) convierten la emisión en un recurso declarativo con reconciliación, y esa es la razón pragmática de que casi todos los clusters serios acaben usándolo: convierte los certificados en objetos del cluster gestionados como cualquier otro manifest, con sus eventos, sus reasons y su auditoría.

PKI privada contra PKI pública

La decisión entre PKI privada y pública depende de quién es el relying party. Para tráfico interno entre servicios, donde los consumidores están bajo el mismo control operativo, una PKI privada tiene todas las ventajas: control total sobre restricciones, duraciones, nombres y políticas. Para endpoints expuestos a navegadores y clientes externos, una PKI pública (Let’s Encrypt, ZeroSSL, las CA gestionadas por los hyperscalers) es el único camino razonable, porque lo que importa es que el cliente confíe sin configuración previa.

Mezclarlas dentro del mismo cluster es habitual y correcto: público en el ingress, privado en la malla. El error clásico es intentar validar tráfico interno con una CA pública (duraciones mínimas de validación, rate limits, dependencia de internet) o intentar servir clientes externos con una CA privada que nadie fuera conoce.

Modos de fallo que todo el mundo descubre tarde

Rotación de raíz

La rotación del certificado raíz es el escenario que nadie quiere y todo el mundo pospone. Implica distribuir la nueva raíz a todos los trust stores antes de empezar a emitir contra ella, convivir dos raíces durante un periodo suficientemente largo para abarcar todos los ciclos de despliegue y rotaciones de imágenes, y retirar la antigua solo cuando la evidencia dice que nada la usa. Saltarse cualquiera de esos pasos significa una interrupción general en el momento del switchover.

Si nunca has ensayado una rotación de raíz, considera que no la tienes. Lo mismo que las copias de seguridad sin restauración probada.

Restricciones olvidadas

Name Constraints, Path Length Constraints y Extended Key Usage son los campos que nadie mira hasta que aparece un incidente. Una CA intermedia sin path length permite crear sub-intermedias sin límite, multiplicando la superficie de compromiso. Una CA sin Name Constraints puede firmar certificados para cualquier dominio, incluido dominios que pertenecen a terceros. Un key usage demasiado amplio convierte un certificado de TLS en un potencial firmante de tokens. Cada una de esas restricciones se pone en la emisión y nunca se puede añadir después.

La dependencia oculta

El patrón recurrente es el certificado intermedio expirado que “no debería” romper nada porque “ya no se usa”, hasta que algún cliente antiguo lo encuentra en la cadena y falla. La regla sana es tratar cada certificado en cada trust store como una dependencia explícita, inventariarlo y rotarlo conscientemente.

Horizonte post-cuántico

El NIST (National Institute of Standards and Technology) publicó en 2024 los primeros estándares de criptografía post-cuántica: FIPS 203 (ML-KEM, basado en CRYSTALS-Kyber), FIPS 204 (ML-DSA, basado en CRYSTALS-Dilithium) y FIPS 205 (SLH-DSA). La PKI actual descansa en RSA y ECDSA, ambos rompibles por un ordenador cuántico suficientemente grande. La transición no es un flag day: consiste en introducir certificados híbridos que lleven firma clásica y firma post-cuántica a la vez, permitiendo que clientes antiguos sigan funcionando mientras los nuevos validan con el algoritmo fuerte. La conversación dentro de TLS y X.509 sobre perfiles híbridos está abierta en el IETF y las decisiones arquitectónicas de hoy (longitud de cadena, tamaño de claves, capacidad del data plane) determinarán si esa migración es operativamente viable.

La decisión razonable ahora no es migrar a post-cuántico, es asegurar que la PKI actual puede sustituir algoritmos sin reescribir la jerarquía. Si la CA raíz está atada a un algoritmo concreto sin plan de crypto-agility, la migración futura será una reconstrucción.

Cuándo la PKI exige atención explícita

La PKI deja de ser invisible y pasa a ser un proyecto con presupuesto propio en cuanto el sistema tiene varios clusters federados, cuando hay requisitos de cumplimiento (SOC 2, PCI DSS, ENS), cuando se emiten certificados para consumidores externos con SLA, cuando se integra con hardware criptográfico o cuando la continuidad del negocio depende de la disponibilidad de la CA. Por debajo de ese umbral, apoyarse en cert-manager con emisores gestionados y documentar la rotación es suficiente. Por encima, hace falta un equipo que entienda jerarquías, ceremonias de firma, HSM, crypto-agility y recuperación ante desastres.

Encaje con el resto de la arquitectura

PKI es la capa más baja de la seguridad criptográfica y sostiene casi todo lo demás: mTLS entre servicios, SVID de SPIFFE, firmas de admisión, tokens firmados, cifrado en reposo con KMS, federación con IdP externos. Cambiar de PKI sin tocar esas capas es imposible, y por eso el diseño inicial condiciona todo lo que viene. Pensar la PKI desde el principio con rotación, jerarquía, restricciones y crypto-agility no es sobre-ingeniería, es la diferencia entre un sistema que evoluciona y uno que se reescribe entero cada vez que hay que cambiar un algoritmo.

Artículos relacionados en esta serie

• mTLS
• SPIFFE y SPIRE
• Gestión de secretos
• API Gateway, BFF y Service Mesh
• Identidad de workload en la nube

Referencias

• RFC 5280 (mayo 2008). Internet X.509 Public Key Infrastructure Certificate and CRL Profile.
• RFC 6960 (junio 2013). Online Certificate Status Protocol (OCSP).
• NIST FIPS 203 (2024). Module-Lattice-Based Key-Encapsulation Mechanism Standard.
• NIST FIPS 204 (2024). Module-Lattice-Based Digital Signature Standard.
• NIST FIPS 205 (2024). Stateless Hash-Based Digital Signature Standard.
• CA/Browser Forum. Baseline Requirements.
• Kubernetes. PKI Documentation.