Respuestas a las preguntas más frecuentes sobre seguridad de Kubernetes
El uso de contenedores está en auge. Ello explica que se haya batido el récord de organizaciones que recurren a Kubernetes como plataforma de contenedores que les ayude a investigar métodos de diseño y publicación de aplicaciones más eficaces y rápidos.
Kubernetes centraliza la aplicación y todos los elementos que esta necesita para ejecutarse en cualquier entorno. Aunque su diseño original fue obra de Google, es la entidad Cloud Native Computing Foundation quien se encarga del mantenimiento de la plataforma. Esta automatiza a escala la implantación y la gestión de aplicaciones en contenedores, contribuyendo así a acabar con las complicaciones y barreras que llevan aparejados los despliegues rápidos y automatizados de software.
Debido a su progresiva generalización, los contenedores y las herramientas de organización de estos, como Kubernetes, son blanco cada vez más frecuente de los ataques de piratas informáticos. Aunque Kubernetes forma parte ya del panorama empresarial, es esencial que te familiarices con los posibles desafíos clave que conlleva para tus labores de seguridad. Estas son las preguntas sobre seguridad que nos hacen con más frecuencia en relación con Kubernetes.
¿Se pueden ejecutar los contenedores como raíz?
Si un contenedor se ejecuta como raíz y se produce una violación de su seguridad, los atacantes que sean capaces de sortear tus defensas podrían acceder a toda tu red sin restricción alguna. Tras infectar al contenedor, podrán examinar la red, explorar el sistema de archivos, descargar paquetes y ejecutar comandos reservados a usuarios raíz, con total libertad. En casos en los que se hayan sorteado los mecanismos de aislamiento del contenedor y se hayan obtenido privilegios adicionales en el host, es incluso posible que el contenedor se ejecute como raíz bajo el control de un pirata informático.
Los riesgos se pueden mitigar desplegando los siguientes mecanismos de defensa, que impiden que los contenedores se ejecuten como raíz dentro de cualquier clúster:
PodSecurityPolicy es un recurso al nivel de clúster que permite rechazar explícitamente a contenedores y pods que soliciten ejecutarse como raíz en la capa del controlador de admisión de API.
Open Policy Agent es una herramienta de control de directivas que permite aplicar restricciones con una flexibilidad incluso mayor.
¿Se pueden montar volúmenes y directorios sensibles en contenedores?
Es vital contar con visibilidad de los volúmenes y directorios que se van a montar en tus contenedores a través de la configuración «hostPath». Debes tener en cuenta las diversas implicaciones que conlleva montar contenedores dentro de clústeres de Kubernetes. Se pueden montar determinados volúmenes y directorios desde el propio equipo host. No obstante, aunque el montaje de contenedores junto con tareas ordinarias como la creación de registros no plantea complicaciones, conceder este grado de permisos respecto a datos sensibles podría generar problemas de seguridad.
¿Los sistemas de archivos son de lectura o de lectura/escritura?
El ajuste predeterminado es lectura. Si el sistema de archivos de raíz o determinados archivos peligrosos se montaran en formato lectura/escritura, los atacantes podrían aprovechar la vulnerabilidad de escape de contenedores, conocida como «CVE-2016-9962». En caso de que un contenedor sufriera un escape total, el atacante tendrá la capacidad de eliminar el contenedor del entorno restringido y hacer un uso indebido del servidor host subyacente.
¿Se pueden ejecutar pods en modo con privilegios?
Si un contenedor se ejecuta en modo con privilegios, se le concede a este la mayoría de las funcionalidades del sistema disponibles en el host subyacente, con lo que se amplía notablemente la superficie de ataque del contenedor. Considera la posibilidad de deshabilitar por completo el modo con privilegios. Si se precisan más llamadas del sistema, podrás definirlas de manera explícita en SecurityContext de las PodSpec.
¿Qué directivas se han implantado y a quiénes afecta?
Procura hacer auditorías a tus reglas y verificar si estas funcionan según lo previsto. Aunque las herramientas DevOps brindan a los equipos de seguridad un control de directivas más férreo respecto a las cargas de trabajo que se ejecutan dentro de un clúster, hay herramientas de terceros que dan pie a que otra directiva pueda sobrescribir las directivas en vigor o introduzca ajustes erróneos en estas. Por ello, es esencial ejecutar con regularidad comprobaciones manuales de las directivas.
¿Cómo se gestiona la autenticación?
Kubernetes admite varios mecanismos de autenticación, cuyas prácticas recomendadas deben haberse implantado obligatoriamente para acceder a un clúster. Aunque no hay solución perfecta para todos los posibles casos, asegúrate de haber implantado una directiva de autenticación que sea sólida y que incluya la autenticación multifactor (MFA), así como la capacidad de revocar credenciales y de prohibir el uso compartido de estas.
¿De qué modo gestiona Kubernetes los privilegios?
Mediante el control de acceso basado en roles (RBAC). Este se basa en el «principio de mínimo privilegio»; es decir, a los módulos (usuario, proceso, dispositivo o programa) se le deben asignar solo y exclusivamente las autorizaciones mínimas que sean esenciales para desempeñar la función que tienen prevista. La compatibilidad de las autorizaciones con este principio permite limitar los efectos de cualquier ataque. Prueba herramientas que permitan a los equipos de seguridad hacer auditorías al RBAC y bloquearlo, como rakkess, rback, krane y kubectl-who-can.
¿Cómo se almacenan, recuperan, rotan y revocan los secretos de Kubernetes?
Los secretos se deberán gestionar adoptando medidas de precaución para conservar la integridad de tu entorno. Estos objetos se almacenan en la API y etcd de Kubernetes correspondientes o en cualquier otro lugar.
¿De dónde provienen las imágenes de contenedores?
La imagen de un contenedor es un conjunto de datos binario que encapsula una aplicación junto con sus archivos y dependencias de software subyacentes. Las imágenes de contenedores son dinámicas y provienen de fuentes, como Docker Hub, o registros públicos que quizás alojen imágenes maliciosas. Al configurar clústeres, asegúrate de que el registro de la imagen sea fiable y seguro y de que se haya verificado su integridad. Ayúdate de tecnologías de escaneado de imágenes y diseña imágenes base mínimas, para poder reducir al mínimo la superficie de ataque de los contenedores.
¿Cómo se aplican las medidas de seguridad de la red?
La directiva de seguridad de red te permite definir restricciones a las comunicaciones entre los pods. Las comunicaciones de red dentro del clúster, tanto de entrada como de salida, deberían ser tan pormenorizadas como sea posible. Si restringes las fuentes de conexión, dotas de protección a los pods. Si tienes pensado hacer una auditoría de tus comunicaciones de red, ¿por qué no pruebas a usarKubernetes NetworkPolicies o una malla de servicios (p. ej., Istio)?
¿Están vuestros hosts protegidos con medidas de supervisión?
Dado que Kubernetes suele servirse de equipos virtuales o hardware físico para la ejecución de cargas de trabajo, es necesario proteger estos equipos host adecuadamente. Cierra todos los puertos que no sean necesarios, revisa todos los sistemas y asegúrate de que las funciones de red se hayan bloqueado. Considera cumplir los requisitos de seguridad CIS Benchmarks vigentes correspondientes a la protección de sistemas.
¿Qué son las auditorías de Kubernetes?
Las auditorías de Kubernetes proporcionan registros de seguridad sobre eventos y actividades que han tenido lugar en tu clúster. Los registros se deben enviar a un sistema de agregación de registros independiente de modo que los equipos de seguridad los almacenen y los analicen.
¿Cómo funciona Ingress o el equilibrio de carga?
¿Cuáles son las IP externas disponibles? Ingress, objeto de API que gestiona el acceso externo a tu clúster, puede ayudar a equilibrar la carga del tráfico. Si no se supervisa, la API de Kubernetes tiene la capacidad de crear automáticamente equilibradores de carga externos y direcciones IP públicas. Asegúrate de que tus cargas de trabajo no queden expuestas a ataques externos o a usuarios demasiado curiosos.
¿Qué ocurre si tu aplicación sufre un ataque de tipo falsificación de peticiones del lado del servidor (SSRF) o de ejecución remota de código (RCE)?
Analiza de manera pormenorizada ambas hipótesis y sigue los pasos dispuestos en la respuesta ante incidentes, para asegurarte de que las líneas defensivas sean sólidas. Adopta medidas de seguridad que restrinjan los efectos en caso de que el ataque SSRF o RCE tenga éxito.
¿Qué otras medidas puedo tomar en los entornos de Kubernetes como preparación ante cualquier amenaza?
Implanta un modelo de amenazas que abarque las hipótesis de seguridad que manejes con más frecuencia. Elabora un modelo de respuesta que deba seguir tu equipo en caso de avería de un clúster, amenaza interna, error de configuración o ataque informático; el modelado de amenazas puede ser todo lo formal o informal que uno quiera. Te recomendamos como introducción que consultes la entrada de blog de Marco Lancini titulada «The Current State of Kubernetes Threat Modelling».
Asimismo, asegúrate de que se actualicen todos los componentes de terceros y suprime todas las integraciones que estén en desuso: paneles, bibliotecas y complementos son focos de vulnerabilidades dentro del ecosistema de Kubernetes.
A pesar de la atractiva novedad que aporta el ecosistema de Kubernetes, el máximo grado de utilidad que puede alcanzar depende —al igual que cualquier herramienta, sistema o entorno— de que sea seguro.
