Planteamiento y contexto
En un clúster multiinquilino de Kubernetes, un servicio debe usar mTLS para llamar a una API interna. La aplicación puede leer archivos, pero no debe llamar a la API de Kubernetes ni incluir una clave privada de larga duración en su imagen. Diseñe la ruta completa de PodCertificateRequest para solicitar, firmar, proyectar, rotar, revocar y auditar certificados.
Qué evalúa el entrevistador
- Si separa PodCertificateRequest, el CertificateSigningRequest tradicional y las responsabilidades del firmante.
- Si puede explicar cómo los volúmenes proyectados por kubelet aíslan claves, certificados y raíces de confianza.
- Si gestiona la autorización del firmante, los límites de inquilinos, las ventanas de rotación, la eliminación de Pods y el compromiso de nodos.
- Si reconoce que PodCertificateRequest está en fase beta y deshabilitado de forma predeterminada en v1.35, requiriendo una habilitación explícita en v1.36.
Preguntas aclaratorias para hacer
- ¿El certificado es para autenticación de cliente, autenticación de servidor o mTLS mutuo?
- ¿Qué SAN, tiempo de vida, raíces de confianza y semántica de revocación se requieren?
- ¿La versión del clúster, el feature gate, la configuración de tiempo de ejecución y kubelet admiten la proyección de certificados de Pod?
- ¿Puede la aplicación volver a abrir archivos u observar cambios de directorio antes de que expire su certificado?
Estructura de respuesta de 30 segundos
Permitiría que kubelet solicite un certificado en nombre del Pod. El firmante aceptaría únicamente un firmante autorizado y campos de identidad restringidos, y luego entregaría la clave, el certificado y la raíz de confianza a través de un volumen proyectado de solo lectura. La aplicación leería archivos en lugar de llamar a la API y los recargaría durante la rotación. Las solicitudes, la emisión, la proyección y la actualización serían auditables; un fallo retendría un certificado antiguo aún válido o bloquearía nuevas conexiones. Debido a que PodCertificateRequest está en fase beta y deshabilitado de forma predeterminada en v1.35, y necesita un feature gate y configuración de tiempo de ejecución en v1.36, comenzaría con la detección de capacidades y un despliegue canary por grupo de nodos.
Análisis detallado paso a paso
1. Definir los límites de identidad y autorización
El Pod declara un propósito y un firmante de destino, pero no puede elegir una CA arbitraria. La política de admisión vincula el namespace, la cuenta de servicio, las etiquetas del Pod y los firmantes permitidos; el firmante valida el origen de la solicitud, las plantillas de SAN y los algoritmos de clave, rechazando sujetos entre inquilinos. El acceso a la API permanece en kubelet y en los componentes del plano de control, mientras que la aplicación recibe únicamente acceso de lectura a archivos.
2. Diseñar la ruta de solicitud y proyección
Kubelet crea la solicitud del Pod y obtiene el resultado firmado. La clave privada se genera en el nodo, por lo que nunca entra en la imagen ni en una API de negocio. El certificado, la clave y el paquete de confianza se montan por separado con permisos de mínimo privilegio. La proyección utiliza reemplazo atómico para que la aplicación no pueda observar un archivo parcialmente escrito. El nombre del firmante, el tiempo de vida y los SAN se registran como atributos de auditoría.
3. Gestionar la rotación, revocación y fallos
Actualice antes de la expiración y cubra reinicios de kubelet, pérdidas de red e interrupciones temporales de la CA. Mantenga el certificado antiguo hasta que se valide la nueva cadena; si la carga falla, rechace nuevas conexiones y exponga una señal de salud. Elimine las proyecciones tras la eliminación del Pod, cambios en la cuenta de servicio o reciclaje de nodos. La revocación depende del contrato de la CA, como CRL, OCSP o tiempos de vida cortos; Kubernetes no proporciona un comportamiento de revocación universal único para cada firmante.
4. Planificar versiones y observabilidad
Verifique el estado deshabilitado de forma predeterminada en la beta de v1.35, el feature gate y la configuración de tiempo de ejecución de v1.36, así como la matriz de compatibilidad entre firmante y kubelet antes del despliegue. Monitoree la latencia de solicitudes, los fallos de emisión, el tiempo de vida restante, el éxito de rotación, los errores de permisos y los SAN inesperados. Los registros deben contener el UID de la solicitud, el namespace, el Pod, el firmante y el resultado, nunca claves privadas ni cuerpos completos de certificados. Mantenga una ruta de proyección heredada de corta duración y un interruptor de reversión durante el canary.
Respuesta de muestra de alta calidad
Trataría un certificado de Pod como una credencial de identidad de corta duración intermediada por kubelet. La admisión vincula el namespace y la cuenta de servicio a un firmante permitido; el firmante valida los SAN, los algoritmos, el tiempo de vida y los límites de inquilinos. La clave se genera en el nodo, mientras que el certificado, la clave y la raíz de confianza se entregan como archivos proyectados de solo lectura separados. La aplicación nunca llama a la API: observa el directorio o vuelve a abrir archivos por solicitud y cambia de forma atómica solo después de validar la nueva cadena. La rotación comienza temprano; una interrupción temporal mantiene el certificado antiguo aún válido, mientras que la expiración o el cambio de identidad bloquea nuevas conexiones y genera una alerta. La eliminación del Pod elimina la proyección y la revocación sigue el contrato del firmante para tiempos de vida cortos o CRL/OCSP. Antes del despliegue, verifico el estado beta deshabilitado de forma predeterminada en v1.35 y el feature gate y la configuración de tiempo de ejecución en v1.36, y luego realizo un canary por grupo de nodos mientras registro el UID de la solicitud, el firmante, la latencia, la tasa de fallos y el tiempo de vida restante.
Errores comunes
- Dar a la aplicación un token de la API de Kubernetes que pueda crear CSR arbitrarios.
- Permitir que los solicitantes elijan cualquier firmante, SAN o sujeto entre namespaces.
- Poner claves privadas en imágenes, ConfigMaps o Secrets de larga duración mientras se ignoran los permisos de los nodos.
- Leer el certificado únicamente al inicio y continuar usando un descriptor de archivo caducado tras la rotación.
- Tratar la capacidad beta como habilitada y estable en todas las versiones del clúster.
- Registrar datos PEM completos, claves privadas o campos de auditoría sensibles de los inquilinos.
Preguntas y respuestas de seguimiento
¿Por qué no usar un Secret de larga duración?
Un Secret de larga duración amplía la ventana de exposición y es difícil de vincular a la identidad y eliminación del Pod. Los certificados de corta duración con proyección de kubelet y rotación reducen el tiempo de vida de la credencial, pero el contrato de revocación y recuperación del firmante debe permanecer explícito.
¿Cómo limita un nodo comprometido?
Restrinja el acceso del nodo a los directorios de Pods y usuarios de contenedores, utilice tiempos de vida cortos y SAN mínimos, y ubique identidades de alto valor detrás de un firmante aislado o protegido por hardware. La auditoría y la detección de conexiones anómalas reducen el tiempo de respuesta.
¿Qué pasa si el feature gate está deshabilitado?
Haga que el deployment controller detecte el recurso de la API, la configuración de tiempo de ejecución y la capacidad de kubelet. Pause la carga de trabajo o cambie a una ruta heredada auditada cuando falten los requisitos previos; nunca cree silenciosamente archivos que parezcan válidos pero que no vayan a rotar.