Prácticas seguras de contenerización

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Todo el mundo sabe que Kubernetes ha ganado la guerra de los contenedores. Pero lo que Kubernetes ha ganado en realidad es la guerra de los entornos de ejecución de contenedores. La guerra de las imágenes de contenedor, en cambio, la ganó Docker. Así lo demuestra el dato de que cada dos semanas se descargan más de mil millones de contenedores Docker, según el Informe sobre el estado de la seguridad del código abierto de 2019. Docker Hub se ha convertido para las empresas en lo que la App Store de Apple y Google Play son para los consumidores.

Las imágenes de contenedor abarcan desde sistemas operativos base hasta pilas de aplicaciones, pasando por bases de datos, middleware y motores de aplicaciones compatibles con node.js, Python y Go. Incluso incluyen integraciones del ecosistema para servicios de aplicaciones.

Si su organización es como la mayoría de las que implementan contenedores, probablemente esté implementando imágenes de Docker en un entorno de Kubernetes.

Y si estás haciendo eso, probablemente también estés desplegando imágenes de contenedor vulnerables. El estudio de Snyk mencionado anteriormente reveló que «cada una de las diez imágenes predeterminadas de Docker más populares contiene al menos 30 bibliotecas del sistema vulnerables». El informe añade que es habitual «que las bibliotecas del sistema estén presentes en muchas imágenes de Docker, ya que estas dependen de una imagen principal que suele utilizar una distribución de Linux como base».

Así pues, las organizaciones descargan continuamente una gran cantidad de imágenes vulnerables. Según Snyk, el número de vulnerabilidades aumenta de forma constante en las tres principales distribuciones de Linux.

Por tanto, no sorprende que el informe «Estado de la seguridad de los contenedores en 2019» de Tripwire revelara que un asombroso 60 % de los encuestados había sufrido un incidente de seguridad relacionado con contenedores en los doce meses anteriores. En casi uno de cada cinco casos (17 %), probablemente se debió a que la organización conocía las vulnerabilidades, pero desplegó las imágenes de todos modos. Y eso a pesar de que Snyk descubrió que, para el 44 % de las imágenes de Docker que contenían vulnerabilidades conocidas, había disponibles imágenes base más recientes y seguras. En otras palabras, simplemente descargar una imagen actualizada habría mitigado el riesgo. Otro 22 % de esas imágenes con vulnerabilidades podría haberse corregido con solo volver a compilar la imagen.

De verdad. No me estoy inventando nada de esto.

Gran parte del énfasis en «desplazar la seguridad a la izquierda» se centra tanto en implementar los servicios adecuados de seguridad de aplicaciones (protección contra bots, cortafuegos de aplicaciones web y control de identidades y accesos) como en incorporar prácticas seguras al ciclo de vida de desarrollo y entrega. Estas prácticas incluyen analizar el código y los contenedores en busca de vulnerabilidades conocidas y, después, corregirlas.

​Ese énfasis iba dirigido al 17 % de vosotros que conocíais las vulnerabilidades de una imagen de contenedor, pero la desplegasteis sin corregirlas.

Podemos hacerlo mejor. Sí, la rapidez es importante, pero la rapidez sin seguridad es peligrosa, no solo para la organización, sino también para los clientes que, en última instancia, utilizan las aplicaciones que lanzas a toda prisa.

Si aún no aplica prácticas seguras de contenerización, considere poner en práctica los siguientes pasos:

1. Evalúe el uso. Muchas organizaciones no son conscientes de hasta qué punto utilizan código fuente e imágenes de código abierto y de terceros. Comprender el alcance de este uso es un primer paso importante. No se pueden abordar las vulnerabilidades de un software que ni siquiera se sabe que se está utilizando.
2. Estandarice. Intente encontrar puntos en común entre las aplicaciones y las operaciones, y estandarice el menor número posible de imágenes y componentes de contenedores. Esto distribuirá la responsabilidad de la seguridad por toda la organización y, en última instancia, mejorará la seguridad para todos.
3. Revisiones de código seguras. Si incluye componentes o scripts de terceros (y es casi seguro que así sea), revíselos y distribúyalos o compílelos desde un repositorio privado.
4. Auditorías de seguridad de contenedores. Si utiliza imágenes de terceros, audite y certifique su seguridad y, a continuación, distribúyalas desde un repositorio privado.
5. Suscríbete a los canales de seguridad. Si dependes de una imagen o de código fuente, busca los canales a través de los cuales se comunican posibles vulnerabilidades y suscríbete a ellos. Al fin y al cabo, estar al tanto es la mitad de la batalla.

Sobre el autor

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Lori MacVittie es ingeniera distinguida y evangelista jefe en la Oficina del CTO de F5, y cuenta con una amplia experiencia en entrega de aplicaciones, estrategia de automatización e infraestructura. Es conocida por convertir la complejidad en claridad, ya sea definiendo mecanismos de protección para agentes de IA, analizando arquitecturas multinube frágiles o explorando los límites de los sistemas escalables. Aporta más de treinta años de experiencia en el sector en desarrollo de aplicaciones, arquitectura de TI y operaciones de redes y sistemas. Antes de incorporarse a F5, fue una galardonada editora de tecnología. MacVittie posee un máster en Informática y es una autora prolífica cuyas publicaciones abarcan la seguridad, la nube y la arquitectura empresarial. También es una apasionada de los juegos de mesa y los videojuegos, y expresa sin complejos sus firmes opiniones sobre el queso.

Más artículos de Lori Mac Vittie