En muchos aspectos, los años aportan refinamiento. El vino, el queso y, en algunos casos, las personas, todos mejoran con el paso del tiempo. Pero en el universo de la TI empresarial, la edad tiene una connotación distinta. Lo que los viejos sistemas y software pueden traer es inadecuación y deuda técnica y, en el peor de los casos, mayores riesgos para la seguridad. Con el surgimiento de los contenedores de Linux como sostén funcional de la empresa en vías de transformación digital, los efectos adversos de la longevidad tecnológica se convierten en el tema central.
En términos más simples, los contenedores envejecen como la leche, no como el vino. Pensémoslo en términos de alimentos: la leche es un componente esencial al momento de cocinar, desde postres hasta salsas. Si se agria o se echa a perder, la receta será un desastre. Lo mismo sucede con los contenedores, especialmente si se los considera componentes clave de los sistemas de producción. Un contenedor rancio o que se tornó “agrio” podría arruinar una implementación que de lo contrario habría sido prometedora.
En este ámbito, “vejez” podría significar algunas semanas y, sin duda, meses. Es tiempo suficiente para acumular vulnerabilidades de seguridad, parches de software y otras actualizaciones críticas, haciendo que una aplicación basada en contenedores antigua sea más inestable y no apta para producción. En entornos informáticos empresariales complejos, un sistema es tan seguro como su eslabón más débil, lo que significa que un contenedor obsoleto podría ser el escenario ideal para que actores malintencionados desmantelen cargas de trabajo, roben datos, o peor aún.
Por ejemplo, en marzo de 2018, la compañía de ciberseguridad Tenable analizó miles de archios de un repositorio de imágenes de contenedores comunitario conocido. En promedio, las imágenes seleccionadas por la comunidad fueron recuperadas con casi 40 vulnerabilidades. Lo que es incluso peor, el 34% eran críticas, y podían incluir amenazas como Heartbleed y Shellshock. En cierto modo, estas imágenes actúan como una cápsula del tiempo, enviando problemas que se creían ya resueltos nuevamente a los sistemas (potencialmente) de producción.
La pregunta que surge ahora es: ¿Cómo rejuvenezco mis viejos contenedores? La respuesta es desoladoramente sencilla: no puede hacerlo.
Está bien que los contenedores envejezcan
Cuando se operan aplicaciones en contenedores se debe tener en cuenta que las imágenes de éstos no pretenden ser guardadas y cuidadas para el largo plazo; tienen un propósito específico y, una vez alcanzado o que el contenedor ya no lo cumpla, deben eliminarse. La propia naturaleza de los contenedores implica que la colocación de parches y las actualizaciones, según nuestra manera de pensar tradicional, no sean posibles. En su lugar, se deben implementar nuevos contenedores que reemplacen a los viejos, con funciones elementales actualizadas para encarar mejor el cambiante ecosistema de software.

Es importante visualizar las cargas de trabajo contenerizadas como una línea de montaje: se descarta la que no tiene buen aspecto o en cierto modo “no encaja”, dado que se pueden introducir nuevas de manera más sencilla. Pero no puede reemplazar a aquellos que tengan componentes obsoletos o que ya no cubran las necesidades si no SABE que poseen estas características. Si bien los contenedores de Linux son intrínsecamente open source, no son totalmente transparentes; la cantidad de megadatos y tecnologías complementarias que rodean a las aplicaciones contenerizadas fácilmente pueden ofuscar su funcionamiento interno y, lo que es más importante aún, la edad de todos sus componentes.
Seguridad: se trata de un ecosistema, no de un trabajo
La seguridad, especialmente la de los contenedores, requiere del esfuerzo conjunto —o al menos de un ecosistema— para ser debidamente abordada. En primer lugar, el contenedor debe ser diseñado teniendo en cuenta los resguardos de seguridad apropiados, pero eso es sólo uno de los pasos. El desarrollador o ISV que crea la aplicación contenerizada necesita adoptar las medidas adecuadas para proveer una aplicación sin vulnerabilidades al momento de crearla, al igual que lo haría con un paquete de software tradicional.

Cuando la aplicación pasa al equipo de operaciones para su implementación, se necesita habilitar los controles de seguridad correspondientes, no sólo en relación con el contenedor mismo, sino también con el host del contenedor. Como se mencionó anteriormente, una solución de contenedores es tan segura como su eslabón más débil. Las fallas en el sistema operativo host, gracias a un kérnel compartido, pueden generar problemas de seguridad con un efecto casada en las operaciones de implementación si no son debidamente resueltas.
Pero la implementación no pone fin a las necesidades de seguridad de los contenedores. Los equipos de operaciones y seguridad deben estar atentos a los anuncios de erratas y vulnerabilidades futuros, y evaluar si alguna de sus aplicaciones contenerizadas está en riesgo. Si detectan contenedores vulnerables, el ciclo se repite con aplicaciones contenerizadas reconstruidas —no con parches— para mitigar el problema. Es un ciclo que debe sostenerse, de manera segura, para que los contenedores estén libres de las vulnerabilidades conocidas.
En pocas palabras, en el universo de los contenedores, es responsabilidad del proveedor de los contenedores (ya se trate de un ISV externo o de un equipo de desarrollo interno), y no del usuario final, incorporar actualizaciones de seguridad de manera continua y generalmente frecuente.
Los cimientos son importantes
Además de la edad, los usuarios finales suelen dar por supuesto lo que sustenta a los contenedores: el sistema operativo. Si bien los contendores únicamente “contienen” los componentes necesarios del sistema operativo host para funcionar, todos comparten el mismo kérnel. Cada contenedor de Linux parte de una capa base de ese sistema operativo, lo que significa que cada ISV que construya imágenes de contenedores está distribuyendo contenido Linux. Para usar estos contenedores en entornos de producción, se deben eliminar todas las vulnerabilidades conocidas de este contenido. Un sistema operativo con vulnerabilidades conocidas podría comprometer toda la línea de producción de contenedores, independientemente del estado en que se encuentren.

Una plataforma de contenedores diseñada con tecnologías genuinamente empresariales y comprobadas puede dar respuesta a estas inquietudes a través de una única capa de tecnología. Más allá de aportar una base más segura y estable, esta plataforma también incluiría Kubernetes para la organización de contenedores, la implementación/restauración automática de imágenes y un método para gestionar múltiples usuarios. Las capacidades adicionales también comprenderían, entre otras, la gestión del ciclo de vida, el almacenamiento, la conexión en red, el registro y anotación de los contenedores. Una plataforma de contenedores debería tener más de un recurso. Todo esto proporciona una plataforma confiable única para las iniciativas de contenedores y un mecanismo de ayuda para que las implementaciones de producción funcionen como deben.
Del caos a la certeza
A primera vista, los contenedores son simples. Son una aplicación o proceso que incluye todas las dependencias necesarias; pero nada es fácil con la TI empresarial. Como observábamos anteriormente, alrededor de cada contenedor existe una gran cantidad de metadatos, desde el momento de su creación y quién lo creó, hasta de qué registro provino y cuándo se implementó. No difiere tanto del manifiesto de un contenedor de transporte físico, pero es mucho más complejo.

Estos metadatos son tan complejos y difíciles de cotejar, especialmente a escala, que es posible que algunas organizaciones simplemente los ignoren. No se puede exagerar la importancia de esta información; sin ella, es posible que los equipos de TI dejen de ver señales críticas de que a una aplicación contenerizada le falta una actualización vital o, peor aún, que tiene componentes obsoletos y potencialmente vulnerables. Pero en aquellas organizaciones que tal vez desarrollen, implementen y vuelvan a implementar miles de contenedores con una cadencia regular, termina siendo una evaluación de los riesgos versus la práctica estándar.
Pero no necesita ser así.
Datos más claros para una menor cantidad de “cajas negras”
En el reciente Red Hat Summit se anunció el lanzamiento del primer Container Health Index o Indicador de Salud de los Contenedores de la industria, que consolida los distintos metadatos que rodean a las imágenes de contenedores y proporciona un “certificado de frescura” de la imagen misma que es fácil de entender. Este indicador toma en cuenta la edad de los contenedores y las erratas de seguridad no aplicadas, entre otras cosas. Desde su lanzamiento, el Container Health Index no ha permanecido estático; se ha desarrollado y construido el programa para que refleje un mundo donde los contenedores no sean “éxitos pasajeros” y las implementaciones de Kubernetes monitoreen decenas, sino cientos, de miles de imágenes de producción.

Al combinarlo con Red Hat Enterprise Linux, la plataforma Linux empresarial líder del mundo, y Red Hat OpenShift, la plataforma Kubernetes de grado empresarial de Red Hat, no sólo ofrecemos una vista más limpia del estado de las aplicaciones contenerizadas sino que también proveemos tecnologías para hacer que sus soluciones nativas de la nube sean más seguras. Los contenedores de Linux representan un poderosa vía hacia la transformación digital pero no importa cuán evolucionada se torne la TI empresarial, la seguridad sigue siendo protagonista. A través de las innovaciones en contenedores de Linux y el compromiso de proveer tecnologías más seguras en cada capa de la tecnología empresarial, Red Hat está listo para convertirse en su socio de software de confianza, ya sea que esté incursionando en el tema o ya implemente contenedores de Linux en modo de producción.