En muchos aspectos, los años aportan refinamiento. El vino, el queso y, en algunos casos, las personas, mejoran con el paso del tiempo. Sin embargo, en el universo de la TI empresarial, la edad tiene una connotación distinta.
Lo único que los viejos sistemas y softwares 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, 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.
La pregunta que surge ahora es: ¿Cómo rejuvenezco mis viejos contenedores? Y la respuesta es desoladoramente sencilla: no puedes.
Hagas lo que hagas, los contenedores envejecen
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 puede cumplirlo, debe eliminarse. En su lugar, se deben implementar nuevos contenedores que reemplacen a los viejos, con funciones elementales actualizadas para encarar mejor el cambiante ecosistema.
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: un ecosistema, no un trabajo
Al hablar específicamente de la seguridad 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 ese 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 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 contener. Las fallas en el sistema operativo host, gracias a un kérnel compartido, pueden generar problemas de seguridad con un efecto cascada 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.
En pocas palabras, en el universo de los contenedores, es responsabilidad del proveedor de los mismos (ya sea un ISV externo o un equipo de desarrollo interno) y no del usuario final, incorporar actualizaciones de seguridad de manera continua y 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 contenedores ú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.
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 la anotación de los contenedores. 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. Se trata de 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 la 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.
Datos claros: menos “cajas negras”
En la Red Hat Summit 2017 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.
