Uso seguro de contenido de terceros

Esta es la parte final de una serie de cuatro partes sobre cómo crear una estrategia de AppSec para Kubernetes.

Las partes anteriores están disponibles aquí:

• Seguridad de contenedores durante todo el SDLC

• Adoptar un enfoque de seguridad shift-left implica cambiar la cultura, no solo las herramientas

• De la seguridad de imágenes a la seguridad de las cargas de trabajo

Un tema que no hemos abordado al hablar de la seguridad de las aplicaciones en Kubernetes es la diferencia entre las aplicaciones propias y las de terceros.

Desde la perspectiva de tus sistemas de producción, en realidad no hay mucha diferencia entre ambas. Tanto si escribiste la aplicación como si lo hizo otra persona, hay muchas similitudes. En cualquier caso, la aplicación tiene cierto acceso a los datos de producción, y sus vulnerabilidades podrían provocar algún nivel de compromiso de esos datos o de los sistemas asociados. Desde una perspectiva clásica de operaciones, es fácil tratar igual las aplicaciones propias y las de terceros. Pero ¿qué ocurre cuando trasladamos parte de las responsabilidades de operaciones a los equipos de desarrollo?

Empaquetado de aplicaciones

En Kubernetes, es común instalar aplicaciones de terceros con una herramienta como Helm. El repositorio de Helm Charts contiene configuraciones para cientos de aplicaciones, desde aerospike hasta zetcd, lo que permite ahorrar mucho tiempo. Además, los proveedores de software que distribuyen productos para consumidores recurren cada vez más a Helm para empaquetar sus aplicaciones. Un chart de Helm contiene la configuración necesaria para instalar la aplicación, que a su vez suele hacer referencia a un conjunto de imágenes de terceros. Más recientemente, hemos visto que los Cloud Native Application Bundles (CNAB) siguen un patrón similar.

Veamos rápidamente un ejemplo de Helm chart, en este caso para Linkerd.

$ tree
.
├── Chart.yaml
├── README.md
├── templates
│ ├── NOTES.txt
│ ├── _helpers.tpl
│ ├── config.yaml
│ ├── daemonset.yaml
│ ├── ingress.yaml
│ └── service.yaml
└── values.yaml

1 directory, 9 files.

¿Qué elementos del chart podrían afectar la seguridad? En el archivo Values.yaml encontramos detalles de algunas imágenes de contenedor, que podrían contener vulnerabilidades:

image: buoyantio/linkerd:1.1.2
image: buoyantio/kubectl:v1.6.2

El archivo de valores también establece límites de recursos razonables

resources:
limits:
cpu: 500m
memory: 512M

Las plantillas, en particular el daemonset, contienen una especificación de contenedor en la que se pueden configurar diversas propiedades de seguridad, como si los contenedores se ejecutan como root, si tienen un sistema de archivos de solo lectura, si solicitan únicamente las capacidades que necesitan, si se establece una política de seguridad de pods, etc.

Aplicaciones de terceros durante todo el SDLC

¿Cómo se relacionan estas consideraciones sobre el empaquetado con nuestro SDLC y con la forma de aplicar la seguridad durante todo el ciclo de vida?

• Local: si usas charts de terceros, es posible que ninguno de tus equipos de desarrollo trabaje con ellos de forma local.

• CI/CD: según cómo instales los charts, podrías tener una referencia a ellos en algún archivo de configuración (como Helmfile o Terraform, por ejemplo), pero lo más probable es que no tengas pruebas configuradas allí, salvo quizá algunas pruebas de humo.

• Registros: los charts de Helm suelen hacer referencia a imágenes en repositorios públicos. Por lo general, es posible reemplazarlas por imágenes internas, pero necesitarás un proceso para mantener actualizadas las copias internas de esas imágenes.

En el caso de una aplicación independiente, es muy posible que hoy la primera oportunidad para detectar vulnerabilidades sea al implementarla en producción. Esto crea una desconexión entre la realidad de trasladar a los desarrolladores las decisiones sobre el contenido de terceros y la capacidad de nuestras herramientas para ofrecer comentarios rápidos sobre la seguridad de esas aplicaciones.

Tipos de aplicaciones de terceros

A grandes rasgos, podemos clasificar las aplicaciones de terceros en dos grupos:

• Aplicaciones independientes que ofrecen un valor específico y concreto, como WordPress o Jenkins.

• Dependencias directas de una aplicación propia, como Redis o PostgreSQL.

Cuando analizamos cómo se incorporan las aplicaciones de terceros a nuestros entornos, veremos por qué esta distinción es útil. Las aplicaciones independientes suelen ser una preocupación mayor para los equipos de operaciones o de plataforma. Un equipo central las instala y administra, y las ofrece como servicio a otros equipos de desarrollo. Las dependencias directas suelen estar a cargo de cada equipo de desarrollo. Para resolver los problemas de seguridad de la cadena de suministro de terceros, debemos considerar ambas perspectivas.

Conclusiones

¿Qué podemos hacer frente a este problema? La respuesta es impulsar una mayor automatización y diseñar pipelines que faciliten la validación y las pruebas del contenido de terceros en etapas más tempranas. Este pipeline debe funcionar tanto para las aplicaciones independientes (que quizá no tengan un pipeline existente) como para probar las dependencias de las aplicaciones existentes.

Para resolver esto, debemos considerar toda la cadena de suministro de software. Necesitamos herramientas locales que nos ayuden a verificar rápidamente un Helm Chart, un Operator o un paquete similar de configuración y referencias a imágenes. Necesitamos pipelines de CI/CD que podamos poner en marcha rápidamente a pedido para asegurarnos de entender cómo los cambios en el contenido de terceros afectan el riesgo de usarlo. También necesitamos pipelines optimizados para incorporar imágenes externas a nuestro entorno de confianza. Sería bueno que surgieran estándares para compartir datos confiables sobre vulnerabilidades.

Es posible usar aplicaciones de terceros de forma segura en un entorno donde las responsabilidades se están trasladando rápidamente a los desarrolladores. Pero eso implica considerar el proceso para hacerlo y luego incorporar la mayor parte posible de ese proceso al SDLC seguro.