Detección de la deriva de contenedores en Kubernetes mediante controladores de admisión
Los ingenieros de Box crearon un controlador de admisión personalizado y un plugin de kubectl para detectar cambios en los contenedores en tiempo de ejecución y aplicar políticas de desalojo de pods.
Traducido automáticamente del original en inglés.
En una publicación del blog de Kubernetes en diciembre de 2021, los ingenieros de Box describieron un sistema que desarrollaron para detectar y gestionar la deriva de contenedores causada por comandos interactivos. El equipo creó un controlador de admisión personalizado y un plugin correspondiente de kubectl para identificar los pods modificados mediante kubectl exec o attach y aplicar políticas de desalojo automático.
Qué ocurrió
Box ejecuta cientos de microservicios en Kubernetes para gestionar el streaming de datos a escala de petabytes. Su flujo de trabajo de despliegue se basa en GitOps, utilizando kube-applier para aplicar configuraciones declarativas desde un repositorio Git tras las revisiones de código y las comprobaciones automatizadas. Este proceso garantiza que todos los cambios en los entornos de producción estén registrados, revisados y sean coherentes con el estado deseado definido en el código.
Sin embargo, los desarrolladores pueden eludir estos controles utilizando comandos interactivos como kubectl exec para modificar directamente los contenedores en ejecución. Estos cambios ad hoc generan una "deriva de contenedores", donde el estado activo de un contenedor diverge de su configuración declarada. Dichas modificaciones subvierten los procesos de control de cambios y permiten que los contenedores afectados sigan sirviendo tráfico en producción sin supervisión.
Para abordar esta brecha de seguridad y operativa, Box creó kube-exec-controller, un componente personalizado de Kubernetes, junto con un plugin de kubectl llamado kubectl pi. Este sistema detecta cuándo los desarrolladores interactúan con los contenedores en ejecución, etiqueta los pods afectados y finalmente los desaloja para restaurar el estado declarado. El proyecto se publicó como código abierto para ayudar a otros equipos a gestionar riesgos similares en sus clústeres.
Cómo funciona
La solución aprovecha los controladores de admisión de Kubernetes, que interceptan las solicitudes al servidor API antes de que los objetos se persistan. Específicamente, el equipo utilizó un ValidatingAdmissionWebhook configurado para vigilar las operaciones CONNECT sobre los recursos pods/exec y pods/attach. Cuando un desarrollador ejecuta un comando interactivo, el webhook envía la solicitud al servicio kube-exec-controller para su validación.

El controlador no bloquea la solicitud inicial, ya que una denegación inmediata obstaculizaría la depuración. En su lugar, permite la conexión y etiqueta asincrónicamente el pod objetivo con metadatos como el nombre de usuario del interlocutor y una marca de tiempo. También registra un evento de advertencia en el pod. Un proceso separado dentro del controlador rastrea un temporizador de tiempo de vida (TTL) para cada pod etiquetado. Una vez que expira el TTL, el controlador desaloja el pod. Se prefiere el desalojo sobre la eliminación porque respeta los PodDisruptionBudgets, garantizando que la disponibilidad del servicio se mantenga durante el proceso de limpieza.
Para mejorar la visibilidad y la usabilidad, Box desarrolló el plugin kubectl pi. Dado que los eventos de Kubernetes solo se conservan durante una hora por defecto, el plugin lee las etiquetas y anotaciones adjuntadas por el controlador para proporcionar información legible por humanos sobre las interacciones con los pods. Incluye un subcomando get para ver los detalles de la interacción y un subcomando extend. El comando extend permite a los desarrolladores solicitar más tiempo antes del desalojo actualizando las anotaciones del pod, lo que reinicia el temporizador de desalojo después de pasar por otro webhook de validación.
Detalles clave
- El sistema utiliza un
ValidatingAdmissionWebhookpara interceptar las solicitudes CONNECT depods/execypods/attach. - Los pods afectados se etiquetan con metadatos que incluyen el nombre de usuario del interlocutor y la marca de tiempo de la interacción inicial.
- Los pods se desalojan después de un TTL predefinido, que varía según el entorno (más largo para desarrollo, más corto para producción).
- El desalojo respeta los PodDisruptionBudgets para evitar interrupciones del servicio durante los reinicios forzados.
- El plugin
kubectl piproporciona los subcomandosgetyextendpara ver el estado y solicitar extensiones del TTL. - El proyecto, denominado
kube-exec-controller, fue publicado como código abierto en GitHub por Box.
Por qué es importante
Para los equipos que desarrollan software sobre Kubernetes, mantener la integridad del estado desplegado es crítico para la seguridad y la fiabilidad. El acceso interactivo a los contenedores es una necesidad común para la depuración, pero introduce cambios no registrados que pueden conducir a una deriva de configuración. Sin mecanismos para detectar y revertir estos cambios, los clústeres pueden acumular inconsistencias que dificultan la resolución de problemas y aumentan los riesgos de seguridad.
Este enfoque demuestra cómo los controladores de admisión pueden utilizarse no solo para la aplicación de políticas, sino también para la higiene operativa. Al automatizar la detección y remediación de la deriva, los equipos pueden permitir el acceso necesario para la depuración mientras aseguran que los sistemas de producción eventualmente vuelvan a su estado declarado y revisado. Equilibra la flexibilidad del desarrollador con la gobernanza de la plataforma.
El uso del desalojo en lugar de la terminación inmediata destaca una comprensión madura de las restricciones de producción. Respetar los PodDisruptionBudgets asegura que las medidas de seguridad no provoquen inadvertidamente tiempos de inactividad. Este patrón es aplicable a cualquier organización que utilice Kubernetes donde se requiera una gestión estricta de cambios junto con flujos de trabajo activos de desarrollo y soporte.
Qué puede hacer
- Evalúe sus actuales políticas de seguridad de Kubernetes para ver si los comandos interactivos como
kubectl execestán sin restricciones. - Considere implementar un webhook de admisión de validación para monitorear y registrar las solicitudes de
pods/execypods/attach. - Defina políticas claras de TTL para los pods con deriva basadas en el entorno, con límites más estrictos para los clústeres de producción.
- Utilice el desalojo de pods en lugar de la eliminación al limpiar contenedores con deriva para respetar los presupuestos de disrupción.
- Desarrolle o adopte plugins de
kubectlpara proporcionar a los desarrolladores visibilidad sobre el historial de interacción con los pods y los temporizadores de desalojo. - Revise el proyecto de código abierto
kube-exec-controlleren GitHub para entender los detalles de implementación y adaptarlos a sus necesidades.


