De la seguridad de imágenes a la seguridad de las cargas de trabajo
31 de octubre de 2019
0 minutos de lecturaEsta es la tercera parte de una serie de cuatro partes sobre cómo crear una estrategia de seguridad de aplicaciones (AppSec) para Kubernetes. Encuentra aquí la parte I y aquí la parte II.
En una de nuestras publicaciones anteriores, hablamos sobre cómo el empaquetado de aplicaciones está pasando a manos de los desarrolladores a medida que las organizaciones adoptan los contenedores. Pero no solo el empaquetado está pasando de la administración de sistemas al desarrollo: la gestión de la configuración también.
Kubernetes y el desafío de la configuración
La API de Kubernetes es una potente abstracción para crear sistemas nativos de la nube. Sin embargo, una consecuencia imprevista de esta API tan completa es que los desarrolladores escriben manualmente grandes cantidades de configuración, principalmente en YAML. Por ejemplo, considera esta descripción de un Deployment de Kubernetes:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
Estos archivos de configuración suelen almacenarse en sistemas de control de versiones, a veces junto con el código de la aplicación y otras veces por separado. Solo en GitHub hay más de 1,5 millones de archivos de configuración de Kubernetes públicos.
Inseguros de forma predeterminada
Por desgracia, la amplia superficie de configuración de Kubernetes da lugar a varios posibles problemas de seguridad. La presentación The Path Less Travelled, de Ian Coldwater y Duffie Cooley, resume muy bien algunos de los problemas de seguridad de la configuración predeterminada de Kubernetes. Estas son algunas propiedades comunes de configuración que suelen quedar sin configurar:
Límites de CPU y memoria | Establecer límites para la CPU y la memoria previstas aporta beneficios operativos y de seguridad. En cuanto a la seguridad, se trata de limitar el impacto que pueden tener los posibles ataques de denegación de servicio en la aplicación, en lugar de afectar al nodo y, potencialmente, a todo el clúster. |
runAsNonRoot | De forma predeterminada, los contenedores se ejecutan como usuario root. Esta propiedad lo impide en el entorno de ejecución del contenedor; es decir, si un atacante logra ejecutar un comando en el contexto del contenedor, solo tendrá permisos limitados. |
readOnlyRootFilesystem | De forma predeterminada, el sistema de archivos montado para el contenedor permite escritura. Esto significa que un atacante que comprometa el contenedor también puede escribir en el disco, lo que facilita ciertos ataques. Si tus contenedores no mantienen estado, no necesitas un sistema de archivos con permisos de escritura. |
Capacidades | Las capacidades de Linux controlan, a bajo nivel, lo que hacen los procesos dentro del contenedor: desde escribir en el disco hasta comunicarse por la red. Es posible eliminar todas las capacidades y agregar las necesarias, pero para hacerlo hay que conocer la lista de capacidades. |
Estas propiedades de configuración no son vulnerabilidades en sí mismas, pero por lo general facilitan que un atacante aproveche una vulnerabilidad en una imagen. Si se produce un exploit, las propiedades de configuración pueden amplificar el daño. El nivel de exposición al riesgo no depende solo de las vulnerabilidades que tengas, sino también del contexto en el que se presentan.
La configuración a lo largo del SDLC
A medida que trasladamos más responsabilidades de seguridad a los desarrolladores, resulta interesante analizar el desafío de la configuración segura desde la perspectiva del SDLC, como hacemos con las vulnerabilidades de las imágenes.
Etapa | Descripción | Comentarios | Completitud |
Local | Herramientas locales que ayudan a crear configuraciones teniendo en cuenta la seguridad, desde la integración con los flujos de trabajo de pruebas unitarias hasta las sugerencias en los IDE. Sin embargo, resuelven problemas individuales, no los de equipos u organizaciones. | Rápida | Baja |
CI/CD | Fallar rápidamente la compilación si los archivos de configuración son potencialmente inseguros o no cumplen alguna política interna. Sin embargo, esto debe implementarse en todos los pipelines pertinentes. | Rápida | Variable |
Repositorio | Actualmente, la configuración se almacena principalmente en un sistema de control de versiones (aunque cabe señalar que Helm 3 agrega compatibilidad para almacenar imágenes en registros OCI compatibles). ¿Cómo ayudamos a los desarrolladores a escribir configuraciones seguras entre el envío de pull requests y la creación de ramas? | Media | Media |
Admisión | Los controladores de admisión de Kubernetes bloquean las solicitudes a la API y permiten impedir configuraciones inseguras prohibidas. Sin embargo, es posible que distintos clústeres tengan políticas diferentes. Además, esto afecta las solicitudes nuevas, no las cargas de trabajo existentes. | Lenta | Alta |
Producción | La API de Kubernetes representa la configuración en ejecución: aquí es donde debes prestar más atención a la configuración. Sin embargo, los problemas en esta etapa pueden afectar cargas de trabajo reales, y los ciclos de respuesta para resolverlos pueden ser lentos. | Lenta | Alta |
Al igual que cuando analizamos las pruebas de imágenes de contenedores, hay distintas ventajas y desventajas según la etapa. Probar solo en una etapa puede ofrecer comentarios rápidos, pero menos control, o viceversa. Como ocurre al analizar las vulnerabilidades de las imágenes, un proceso de seguridad moderno y maduro probablemente incluya pruebas de configuración en varias etapas.
Conclusiones
Nuestras aplicaciones no son solo las imágenes que usamos para empaquetarlas, sino también la configuración que usamos para ejecutarlas. En el mejor de los casos, hemos considerado que son dos áreas distintas que deben protegerse. Sin embargo, en la mayoría de los casos, las conversaciones sobre seguridad de contenedores para desarrolladores se han centrado exclusivamente en las vulnerabilidades de las imágenes. A medida que la responsabilidad por la seguridad de las aplicaciones pasa a los equipos de desarrollo, es cada vez más importante entender la relación entre las vulnerabilidades de las imágenes y la configuración, y contar con herramientas que ayuden a proteger ambas.
Empieza con Capture the Flag
Aprende a resolver desafíos de Capture the Flag viendo nuestro taller virtual introductorio a pedido.
