Enunciado y alcance
Esta es una pregunta sobre infraestructura de identidad y confiabilidad del backend. Las ServiceAccounts de Kubernetes utilizan JWT firmados para acceder al servidor de la API o a otros sistemas que confían en dicha identidad. En v1.36, la firma externa de tokens de ServiceAccount es estable, lo que permite que las solicitudes de firma salgan del servidor de la API a través de un socket de dominio Unix local. El diseño debe reducir la exposición de la clave privada mientras preserva las semánticas de TokenRequest, verificación con clave pública, rotación y alta disponibilidad.
Qué evalúa el entrevistador
- Si separa la firma, la emisión, la verificación y la autorización en lugar de limitarse a decir “conectar un KMS”.
- Si diseña el comportamiento de la conexión UDS/gRPC, los límites de tiempo (deadlines), la concurrencia, los reintentos y el manejo de falla cerrada (fail-closed).
- Si maneja la superposición de claves,
kidde JWT, cachés y actualización de los verificadores. - Si rota y revierte sin revocar prematuramente tokens válidos de corta duración.
- Si define métricas de auditoría, latencia, errores y uso de claves.
Preguntas de clarificación para hacer
- ¿Cuáles son el TTL del token, las audiencias, las QPS de emisión y la cantidad de réplicas del servidor de la API?
- ¿El firmador externo proporciona garantías de HSM, pruebas de salud (health probes), claves versionadas e identificadores de idempotencia?
- ¿Cómo obtienen los verificadores el JWKS y cuáles son los retrasos de actualización y los TTL de caché?
- Cuando el firmador no está disponible, ¿se pueden rechazar los nuevos tokens o existe un mecanismo de respaldo controlado con una clave antigua?
- ¿Existen trabajos fuera de línea o sistemas externos al clúster que dependan de estos JWT durante la rotación?
Una respuesta de 30 segundos
“Dividiría la ruta en autorización de TokenRequest, llamadas del servidor de la API al firmador externo, distribución de la clave pública y autorización RBAC. El servidor de la API llama al firmador a través de un socket Unix protegido con un límite de tiempo, ID de solicitud y reintentos acotados; la clave privada permanece dentro del KMS o HSM. Durante la rotación, publique la nueva clave pública y permita que los verificadores la actualicen con superposición, luego emita con el nuevo kid; retire la clave antigua solo después de que expire el TTL del token antiguo. Si el firmador no está disponible, rechace la nueva emisión y genere una alerta en lugar de crear silenciosamente tokens desprotegidos. Mida la latencia de firma, la tasa de rechazo, los errores de socket, los ID de clave y la antigüedad de JWKS, y conserve el firmador y la clave antiguos para la reversión”.
Análisis detallado paso a paso
Paso 1: Definir la confianza y el flujo de datos
La autorización de TokenRequest determina quién puede solicitar un token para qué ServiceAccount y audiencia. Después de validar la solicitud, el servidor de la API envía la carga útil (payload) del JWT al firmador externo; el firmador devuelve una firma y el servidor de la API devuelve el token. El servidor de la API sigue siendo el propietario del emisor, la audiencia, la expiración y la semántica de RBAC. El sistema externo solo realiza la firma controlada y no debe otorgar permisos adicionales.
Paso 2: Diseñar la interfaz del firmador local
La configuración documentada apunta --service-account-signing-endpoint a un socket de dominio Unix donde puede ejecutarse un protocolo de firma versionado. Restrinja los permisos del socket, el directorio, la identidad del proceso y la política de SELinux o AppArmor al servidor de la API. Incluya la versión de la clave, el algoritmo, el resumen o bytes de firma, el ID de solicitud y el límite de tiempo en la solicitud; devuelva la firma, kid y un ID de correlación de auditoría. Nunca coloque claves privadas ni tokens completos en registros ordinarios.
Paso 3: Manejar límites de tiempo, reintentos e idempotencia
La firma es una ruta sensible a la latencia, por lo que se debe utilizar un límite de tiempo corto y una concurrencia acotada. Una falla transitoria de la red o del HSM puede recibir reintentos limitados, pero los reintentos infinitos amplificarían la cola del servidor de la API. Los ID de solicitud correlacionan las auditorías del firmador y del servidor de la API; si el protocolo admite almacenamiento en caché idempotente, se puede evitar la contabilidad duplicada. Tras un tiempo de espera agotado, devuelva un error explícito y rechace la nueva emisión. El hecho de que los tokens existentes continúen verificándose depende de las claves públicas y la política de expiración.
Paso 4: Diseñar la rotación de claves y la superposición de JWKS
Cree una nueva clave y permita que el firmador use su nuevo kid, luego publique la nueva clave pública en JWKS. Después de que los verificadores se actualicen, emita nuevos tokens con esa clave. Conserve la clave pública antigua durante al menos el TTL de token más largo más las ventanas de caché y desfase de reloj (clock skew). No la elimine simplemente porque el emisor haya cambiado. La rotación debe ser pausible, auditable y reversible.
Paso 5: Preservar las réplicas y la recuperación ante desastres
Cada réplica del servidor de la API debe alcanzar un firmador local o de alta disponibilidad con versiones de clave y relojes consistentes. Para un firmador centralizado, evalúe la red entre nodos, los dominios de falla y el radio de impacto (blast radius). Para sidecars por nodo, asegúrese de que la conectividad con el HSM y la distribución de claves no diverjan. Ponga a prueba el reinicio del firmador, la falta de archivos de socket, la limitación (throttling) del HSM, JWKS no disponible y las actualizaciones progresivas del servidor de la API.
Paso 6: Verificar, auditar y revertir
Habilite la configuración en un servidor de la API de prueba tipo canary y verifique el emisor de TokenRequest, la audiencia, kid, la expiración y el comportamiento de RBAC. Ejecute pruebas de integración entre claves antiguas y nuevas, tipos de verificadores y desfase de reloj. Rastree el p50/p95 de firma, los motivos de falla, la latencia del socket, los recuentos del HSM, la antigüedad de JWKS y la tasa de rechazo de tokens. Revierta restaurando la configuración del firmador y la clave antiguos mientras retiene la clave pública antigua; no la elimine hasta que los tokens antiguos y la ventana de auditoría hayan finalizado.
Respuesta de muestra de alta calidad
“Convertiría al firmador externo en un límite de firma acotado. El servidor de la API sigue validando TokenRequest, emisor, audiencia, expiración y RBAC, llama al firmador a través de un socket Unix protegido y mantiene la clave privada únicamente en el KMS o HSM. Las solicitudes llevan versión, kid, ID, límite de tiempo y reintentos acotados; una falla del firmador rechaza nuevos tokens y genera alertas. La rotación publica el nuevo JWKS, espera la actualización del verificador, cambia la emisión al nuevo kid y retiene la clave antigua durante la ventana del TTL más largo, caché y desfase de reloj. Cada réplica debe tener acceso a socket local, versiones de clave y tiempo consistentes. El canary comprueba la latencia, la tasa de rechazo, la distribución de ID de clave, la antigüedad de JWKS y la integración con RBAC, mientras que la reversión preserva el firmador y la clave pública antiguos”.
Errores comunes
- Permitir que el firmador externo decida el RBAC o la audiencia, expandiendo su responsabilidad.
- Copiar la clave privada a un sidecar o a los registros, perdiendo el beneficio de seguridad.
- Eliminar la clave pública antigua inmediatamente después de la rotación e invalidar tokens que aún son válidos.
- Reintentar tiempos de espera del firmador sin límite y saturar la cola del servidor de la API.
- Probar solo la firma exitosa en lugar de las cachés de JWKS, el desfase de reloj y la consistencia de las réplicas.
- Tratar la emisión silenciosa con la clave antigua durante una falla del firmador como un respaldo confiable sin límites de auditoría.
Preguntas de seguimiento y respuestas
¿Puede el servidor de la API seguir usando una clave privada antigua local si el firmador está caído?
Solo si el modelo de amenazas explícito, la auditoría y el plan de reversión lo permiten. El valor predeterminado debe rechazar nuevas emisiones para que los secretos no regresen al servidor de la API. Los tokens existentes pueden continuar verificándose con la clave pública antigua hasta que finalice su TTL.
¿Cuándo es seguro eliminar la clave pública antigua?
Calcule una ventana de seguridad a partir del TTL de token más largo, el TTL de caché de JWKS del verificador, el desfase máximo de reloj y la retención de consumidores fuera de línea; luego verifique que el uso del antiguo kid sea cero. Elimínela solo después de transcurrida la ventana y conserve primero una copia de seguridad recuperable.
¿Por qué usar un socket Unix en lugar de HTTP?
Un socket local reduce la superficie de escucha y utiliza permisos de archivos y políticas del host para controlar el acceso. Por sí solo no resuelve la autenticación de protocolo, el aislamiento de procesos ni la disponibilidad; aún se requieren API versionadas, auditorías, límites de tiempo y simulacros de fallas.