|
Este documento ha sido traducido utilizando tecnología de traducción automática. Si bien nos esforzamos por proporcionar traducciones precisas, no ofrecemos garantías sobre la integridad, precisión o confiabilidad del contenido traducido. En caso de discrepancia, la versión original en inglés prevalecerá y constituirá el texto autorizado. |
|
Esta es documentación inédita para Admission Controller 1.34-dev. |
Modelo de Amenaza
El Grupo de Interés Especial (SIG) de Seguridad de Kubernetes ha definido un Modelo de Amenaza de Control de Admisión para Kubernetes. El equipo SUSE Security Admission Controller evalúa continuamente Admission Controller en relación con este modelo de amenaza y trabaja para proporcionar configuraciones seguras. Se recomienda que los administradores de Admission Controller lean y comprendan el modelo de amenaza, y lo utilicen para idear su propio modelo de amenaza específico para las circunstancias según sea necesario.
Los detalles sobre cada amenaza están en el documento publicado por SIG Seguridad.
Amenazas de Kubernetes
Amenaza 1 - El atacante inunda el webhook con tráfico impidiendo su operación
Escenario
Un atacante que tiene acceso al punto final del Webhook, a nivel de red, podría enviar grandes cantidades de tráfico, causando una denegación de servicio efectiva al controlador de admisión.
Mitigación
El webhook falla cerrado. Si el webhook no responde a tiempo, por cualquier motivo, el servidor API debería rechazar la solicitud. Este es el comportamiento por defecto de Admission Controller.
Fallar cerrado significa que si, por cualquier motivo, Admission Controller deja de responder o falla, el servidor API rechaza la solicitud por defecto. Esto es incluso si la solicitud es normalmente aceptada por Admission Controller.
Amenaza 2 - El atacante pasa cargas de trabajo que requieren procesamiento complejo causando tiempos de espera.
Amenaza 3 - El atacante explota la mala configuración del webhook para eludir.
Amenaza 4 - El atacante tiene derechos para eliminar o modificar el objeto webhook de Kubernetes.
Escenario
Un atacante que tiene acceso a la API de Kubernetes, tiene privilegios suficientes para eliminar el objeto webhook en el clúster.
To-do
La mayor parte de RBAC no está dentro del alcance de la discusión actual. Sin embargo, lo siguiente llegará a su debido tiempo, para ayudar a los usuarios de Admission Controller:
-
Direcciones sobre el mínimo de RBAC que se debe implementar.
-
Provisionar y documentar una directiva que detecte y pueda bloquear cambios en RBAC.
Amenaza 5 - El atacante obtiene acceso a credenciales válidas para el webhook.
Amenaza 6 - El atacante obtiene acceso a una credencial de administrador del clúster.
Amenaza 7 - El atacante intercepta el tráfico en la red de contenedores.
Amenaza 8 - El atacante lleva a cabo un ataque MITM en el webhook
Escenario
Un atacante en la red del contenedor, que tiene acceso a la capacidad NET_RAW, puede intentar utilizar herramientas MITM para interceptar el tráfico entre el servidor API y el webhook del controlador de admisión.
Mitigación
Configura el clúster con autenticación mTLS para los Webhooks y habilita la función mTLS en la pila Admission Controller. Alternativamente, configura mTLS utilizando un CNI que soporte Políticas de Red. Consulta "Webhooks seguros con TLS mutuo" para más información.
Utiliza la política capabilities-psp y configúrala para eliminar las capacidades NET_RAW.
Amenaza 9 - El atacante roba tráfico del webhook mediante suplantación
Escenario
Un atacante puede redirigir el tráfico del servidor API previsto, para el webhook del controlador de admisión, mediante suplantación.
Mitigación
Configura el clúster con autenticación mTLS para los Webhooks y habilita la función mTLS en la pila Admission Controller. Alternativamente, configura mTLS utilizando un CNI que soporte Políticas de Red. Consulta "Webhooks seguros con TLS mutuo" para más información.
Amenaza 10 - Abusando de una regla de mutación para crear un contenedor privilegiado
Amenaza 11 - El atacante despliega cargas de trabajo en espacios de nombres que están exentos del control de admisión
Escenario
Un atacante puede desplegar cargas de trabajo en espacios de nombres de Kubernetes exentos de la configuración del controlador de admisión.
To-do
La mayor parte del RBAC está fuera del alcance respecto a esta decisión. Sin embargo, el equipo Admission Controller tiene como objetivo:
-
Advertir a los usuarios a través de nuestra documentación y sugerir el mínimo RBAC que se debe utilizar.
-
Proporcionar una política que detecte cambios en RBAC y quizás los bloquee.
Amenaza 12 - La regla de bloqueo puede ser eludida debido a una coincidencia faltante (por ejemplo, contenedores de inicialización faltantes)
Amenaza 13 - El atacante explota una mala coincidencia de cadenas en una lista de denegación para eludir las reglas
Amenaza 14 - El atacante utiliza características nuevas/antiguas de la API de Kubernetes que no tienen reglas
Escenario
Un atacante, con derechos para crear cargas de trabajo, utiliza nuevas características de la API de Kubernetes (por ejemplo, una versión de API cambiada) para eludir una regla.
Mitigación
Revisa y prueba todas las reglas. Hay una directiva que prueba el uso de recursos que han quedado obsoletos. Está disponible desde la directiva-de-versiones-api-obsoletas.
deprecated-api-versions-policy solo trata con Recursos Personalizados que conoce. La amenaza son tanto las versiones de recursos que han quedado obsoletos como las nuevas desconocidas que se utilizan de manera incorrecta, por lo tanto, la directiva solo cubre parte del problema.
|
Amenaza 15 - El atacante despliega un contenedor privilegiado en un nodo que ejecuta el controlador de Webhook
Amenaza 16 - El atacante monta un hostPath privilegiado que permite la modificación de la configuración del controlador de Webhook
Escenario
Un atacante, que tiene derechos para desplegar volúmenes hostPath con cargas de trabajo, crea un volumen que permite el acceso a los archivos del pod del controlador de admisión.
Desplegad el kubewarden-default Helm chart y habilitad sus directivas recomendadas, que incluyen la directiva hostpaths-psp. Esta directiva está configurada para reducir los volúmenes hostPath compartidos.
Amenaza 17 - El atacante tiene acceso SSH privilegiado al nodo del clúster que ejecuta el webhook de admisión.
Amenaza 18 - El atacante utiliza directivas para enviar datos confidenciales de las solicitudes de admisión a sistemas externos.
Escenario
Un atacante puede configurar una directiva que escucha las solicitudes de admisión y envía datos sensibles a un sistema externo.
Mitigación
-
Configura el clúster con autenticación mTLS para los Webhooks y habilita la función mTLS en la pila Admission Controller. Alternativamente, configura mTLS utilizando un CNI que soporte Políticas de Red.
-
Por defecto, las directivas de Admission Controller no tienen acceso a la red y se ejecutan en un entorno restrictivo, controlando estrictamente el acceso externo a los Webhooks.
Amenazas de Admission Controller
Amenaza Admission Controller 1 - Inicio de confianza para el controlador de admisión.
Escenario
Suponiendo un clúster de Kubernetes confiable pero nuevo, un atacante puede comprometer la pila Admission Controller antes de su ampliación y de la aplicación de cualquiera de las directivas de seguridad.
Por ejemplo, mediante:
-
el uso de imágenes no firmadas y maliciosas para:
-
Admission Controller-controller
-
servidor-de-directiva
-
cualquiera de las dependencias de Admission Controller
-
cualquiera de las dependencias opcionales (Grafana, Prometheus y otras)
-
-
comprometiendo la carga útil de los gráficos de Helm
Mitigación
-
Admission Controller proporciona un Software Bill Of Materials, que enumera todas las imágenes necesarias. Esto ayuda con Zero-Trust. El administrador de Kubernetes debe verificar las imágenes de Admission Controller, las imágenes de sus dependencias y los gráficos fuera del clúster de Kubernetes, en un entorno de confianza. Puedes hacer esto con
cosign, por ejemplo. Por cierto, esta es parte de la implementación necesaria para instalaciones en un entorno aislado. -
Utiliza gráficos de Helm firmados y resúmenes verificados en lugar de etiquetas para las imágenes de Admission Controller en esos gráficos de Helm. Sin embargo, esto no asegura las dependencias.