Planteamiento y contexto
Un equipo de plataforma debe permitir que kube-apiserver lea métricas de nodo sin otorgar a la misma identidad acceso a los endpoints de depuración o exec de Kubelet. El clúster se está actualizando desde un comportamiento de autorización grueso a Kubernetes v1.36, sin interrupciones en la monitorización, sin expansión de privilegios a nivel de nodo y con evidencia auditable. Explique la ruta de autenticación, los atributos de autorización, la migración, la reversión y las métricas de validación.
Qué evalúa el entrevistador
- Separar la autenticación del endpoint HTTPS de Kubelet de la autorización en lugar de discutir únicamente sobre RBAC.
- Expresar el privilegio mínimo con atributos de verbo, recurso, subrecurso, nodo y namespace.
- Comprender que la identidad del cliente Kubelet del API Server necesita reglas de autorización explícitas.
- Diseñar la migración de compatibilidad, el comportamiento fail-closed, la auditabilidad y la reversión.
Preguntas de clarificación para hacer
- ¿Qué emisores de llamadas necesitan la API de Kubelet: solo el API Server, agentes de monitorización u operadores conectándose directamente a los nodos?
- ¿Qué capacidades se requieren: métricas, registros, estado de contenedores en ejecución, ejecución de comandos o reenvío de puertos?
- ¿Utiliza Kubelet certificados de cliente u otro método de autenticación, y está disponible el callback de autorización del API Server?
- ¿Es aceptable una breve degradación de solo lectura durante el despliegue, y cuál es el presupuesto de indisponibilidad para la monitorización?
Estructura de respuesta de 30 segundos
Divida la ruta en tres capas: TLS u otro autenticador establece la identidad del emisor de la llamada, el autorizador de Kubelet mapea la solicitud a atributos y un servicio de autorización toma la decisión. Aplique reglas de privilegio mínimo solo a los endpoints de nodo necesarios, aislando las capacidades de depuración, exec y proxy. Migre inventariando las llamadas, observando las denegaciones, ajustando las reglas por lotes y cambiando al bloqueo forzado únicamente después de que las métricas y un mecanismo de reversión estén listos.
Análisis detallado paso a paso
1. Autenticación, autorización y atributos de solicitud
El endpoint HTTPS de Kubelet valida primero un certificado de cliente o el autenticador configurado y obtiene un nombre de usuario y grupos. La autorización mapea la solicitud HTTP a atributos de Kubernetes como verbo, recurso, subrecurso, namespace, nombre y nodo. El éxito de la autenticación no implica autorización; cada endpoint necesita una decisión. Cuando el API Server llama a Kubelet, el --kubelet-client-certificate y la clave coincidente identifican un principal controlado que debe tener permisos explícitos en el sistema de autorización.
2. Expresar el privilegio mínimo con subrecursos
Trate las métricas, los registros, el estado de los contenedores y la ejecución de depuración como capacidades separadas. Otorgue únicamente los recursos o subrecursos de nodo de solo lectura requeridos y restrinja el alcance de los nodos. No otorgue recursos comodín ni acceso amplio a nodes/proxy simplemente para que funcione la monitorización. Asigne a la ejecución de comandos, el reenvío de puertos y los endpoints de depuración roles separados de alto riesgo que no estén vinculados a la identidad de servicio ordinaria del API Server.
3. Migración y compatibilidad
Construya una matriz de llamadas a partir de los registros de auditoría y acceso actuales: identidad, ruta, verbo, nodo de destino, resultado y versión del emisor. Tras habilitar la autorización de grano fino, ejecute una fase de observación que registre las posibles denegaciones sin interrumpir la recolección, complete solo las reglas necesarias y cambie los nodos por lotes. KubeletFineGrainedAuthz es GA y está habilitado de forma predeterminada en Kubernetes v1.36, pero el despliegue aún debe verificar los valores predeterminados de la distribución, las credenciales de cliente del API Server y las rutas de cada componente de monitorización.
4. Observabilidad, reversión y defensa en profundidad
Registre eventos de auditoría tanto para permisos como para denegaciones con identidad, nodo, recurso y motivo. Monitorice la latencia de autorización, la tasa de denegaciones, el éxito en la recolección de métricas y los accesos inesperados a endpoints. Si el despliegue interrumpe la monitorización, revierta primero los permisos del cliente o restablezca temporalmente una regla de compatibilidad mientras mantiene cerrados los endpoints de alto riesgo. Los controles de red aún deben limitar la accesibilidad al puerto de Kubelet; la autorización no reemplaza a TLS, el aislamiento de red ni la protección de identidad de los nodos.
Respuesta modelo
Primero verificaría el autenticador del endpoint de Kubelet y luego mapearía cada solicitud a los atributos de autorización estándar. El API Server utiliza un certificado de cliente controlado, y el sistema de autorización evalúa verbo, recurso, subrecurso, nodo y namespace para el privilegio mínimo. La recolección de métricas recibe solo la capacidad de solo lectura requerida. exec, el reenvío de puertos y los endpoints de depuración utilizan roles separados de alto riesgo; los permisos comodín y el acceso amplio a nodes/proxy no se adjuntan a la identidad ordinaria del API Server.
La migración consta de cuatro etapas: inventariar la matriz de llamadas; observar denegaciones sin interrumpir la recolección; agregar reglas mínimas en lotes de nodos y componentes; y luego aplicar la denegación forzada con un mecanismo de reversión. KubeletFineGrainedAuthz es GA y está habilitado de forma predeterminada en v1.36, pero verificaría la configuración de la distribución, las credenciales del API Server y las versiones de monitorización. Los registros de auditoría conservan la identidad, el nodo, el recurso, el resultado y el motivo, mientras que la política de red continúa restringiendo los puertos de Kubelet para que los controles de autorización, transporte y red converjan.
Errores comunes
- Configurar la autenticación TLS y asumir que un certificado de cliente concede acceso a todas las API de Kubelet.
- Usar recursos comodín o permisos amplios de
nodes/proxypara solucionar la monitorización. - Aplicar denegaciones forzadas sin una matriz de llamadas, causando fallos silenciosos en la recolección tras la actualización.
- Reutilizar un único rol de alto privilegio para el API Server y la depuración por parte de operadores.
- Depender únicamente de las reglas de autorización ignorando la exposición del puerto de Kubelet y las alertas de auditoría.
Preguntas de seguimiento y respuestas
Pregunta de seguimiento 1: ¿Por qué no otorgar directamente nodes/proxy a la identidad de monitorización?
nodes/proxy permite el acceso a los endpoints del nodo a través del API Server y puede cubrir mucho más que lecturas de métricas. Confirme las rutas de solicitud reales y otorgue permisos concretos de recursos o subrecursos. Si una restricción de implementación requiere acceso por proxy, asocie una identidad dedicada con limitación de alcance de nodo y alertas de auditoría.
Pregunta de seguimiento 2: ¿Cómo demuestra que la actualización no expandió los privilegios?
Compare la matriz de llamadas y las decisiones de autorización antes y después del cambio, centrándose en nuevos verbos, recursos, subrecursos y alcance de nodos. Analice las diferencias en las denegaciones y luego use solicitudes sintéticas para demostrar que las métricas siguen siendo legibles mientras que exec permanece denegado. Convierta esas comprobaciones en compuertas de liberación (release gates).
Pregunta de seguimiento 3: ¿Qué sucede si el servicio de autorización no está disponible?
Elija una política explícita de fail-closed para que una falla en el callback no se convierta en una autorización permitida. Según el presupuesto del negocio, mantenga una caché de solo lectura breve o pause la recolección, pero no abra endpoints de alto riesgo para restaurar las métricas. Genere alertas y vuelva a validar después de que el callback se recupere.