Cómo le ayuda KernelCare a mantener seguras sus cargas de trabajo en contenedores

La virtualización del sistema operativo supuso un gran paso adelante para la entrega de aplicaciones informáticas empresariales a gran escala. Pero las máquinas virtuales eran sólo el principio. Los contenedores llevan la virtualización un paso más allá, ofreciendo una flexibilidad sin precedentes a medida que las aplicaciones se vuelven casi perfectamente transportables.

Sin embargo, los contenedores conllevan un riesgo de seguridad oculto que se deriva de la naturaleza de la contenedorización. En este artículo, analizamos el papel de la contenedorización en la empresa, explicamos por qué los contenedores pueden suponer un riesgo para la seguridad empresarial y proponemos soluciones eficaces.

Contenido:

1. ¿Qué es una carga de trabajo en contenedores?

2. De la virtualización a la contenedorización

3. Cómo se utilizan los contenedores en la empresa

4. La relación entre los contenedores y el host

5. Aislada, sí, pero aún vulnerable

6. Kernels sin parches: ¿Un riesgo oculto para la seguridad de los contenedores?

7. El problema de parchear los núcleos

8. Integración de KernelCare Live Patching

9. Otros consejos para la seguridad del núcleo del contenedor

10. Conclusión

Espere. ¿Qué es una carga de trabajo en contenedores?

Para entender por qué los contenedores pueden ser un riesgo para la seguridad, es necesario comprender qué es exactamente un contenedor y qué es una carga de trabajo en contenedor.

Primero, un paso atrás en la virtualización. No hace mucho, el sistema operativo de un ordenador y el hardware sobre el que se ejecutaban estaban inextricablemente unidos: un servidor físico estaba asociado a un sistema operativo. La virtualización cambia esta situación al interponer una capa entre el hardware y el sistema operativo que se ejecuta en él. Elimina la relación vinculante de uno a uno entre el sistema operativo y el hardware.

Para un sistema operativo virtualizado parece como si fuera el único sistema operativo en el hardware. En segundo plano, el software de virtualización (el hipervisor) gestiona la capa de abstracción para garantizar que cada sistema operativo desconozca la presencia de otros sistemas operativos en la máquina.

Gracias a la virtualización puedes ejecutar varios sistemas operativos en una sola máquina y transportar fácilmente un sistema operativo de una máquina a otra. El resultado es un aumento de la eficacia y la flexibilidad.

De la virtualización a la contenedorización

Señalamos la virtualización porque ayuda a explicar lo que hace la contenedorización. Mientras que la virtualización coloca una capa de abstracción entre el equipo físico y el sistema operativo, la contenedorización añade una capa de abstracción entre el sistema operativo y la aplicación.

Esencialmente, mientras que la virtualización virtualiza el hardware, la contenedorización virtualiza el sistema operativo. Con la contenedorización, cada aplicación se encapsula en una unidad aislada llamada contenedor. Las aplicaciones en contenedores no comparten el entorno del sistema operativo, porque cada contenedor funciona de forma discreta.

Sin embargo, los contenedores comparten el acceso de sólo lectura a elementos del sistema operativo, incluido su núcleo. No obstante, para cada aplicación, parece que se está ejecutando sola en un sistema operativo propio, y las aplicaciones desconocen mutuamente que comparten el entorno del sistema operativo.

En consecuencia, una carga de trabajo en contenedores se refiere a un entorno en el que las aplicaciones que soportan los requisitos de la empresa se ejecutan en contenedores aislados dentro de un sistema operativo host.

Cómo se utilizan los contenedores en la empresa

Se podría suponer que aislar las aplicaciones dentro de contenedores proporciona beneficios en términos de seguridad y estabilidad, y se estaría en lo cierto. Sin embargo, las ventajas de la contenedorización van mucho más allá.

En esencia, la contenedorización permite a las empresas empaquetar y desplegar aplicaciones en distintos tipos de infraestructura de forma estandarizada. En teoría, cualquier host capaz de alojar un contenedor (compatible) también puede alojar una aplicación en contenedor.

Esto sucede porque la contenedorización abstrae la capa de aplicación. La tecnología de contenedores como Docker facilita esta abstracción de una manera estandarizada. La clave de este comportamiento estandarizado es algo llamado imagen de contenedor. Una imagen de contenedor incluye no solo el código de la aplicación, sino también las bibliotecas del sistema y otras configuraciones clave que garantizan que una aplicación en contenedor esté lista para funcionar.

Esto nos lleva a una ventaja clave de la contenedorización que va más allá de la seguridad y la estabilidad de las aplicaciones: los contenedores son intrínsecamente portátiles. Esto conlleva varias ventajas importantes para las aplicaciones empresariales:

• Portabilidad significa agilidad. Las aplicaciones en contenedores pueden ejecutarse fácilmente en un entorno nuevo y desconocido. Un desarrollador puede publicar una imagen de contenedor y los clientes empresariales pueden desplegar la aplicación con confianza siempre que el contenedor se adapte a un entorno de contenedores estándar como Docker. Los contenedores permiten un despliegue de aplicaciones increíblemente ágil.
• Los contenedores consumen pocos recursos. Es fácil y rápido poner en marcha una aplicación en contenedores, mucho más fácil y rápido que poner en marcha un sistema operativo virtual completo. Al mismo tiempo, una sola máquina anfitriona puede soportar muchos más contenedores que instancias de sistemas operativos virtuales. Por eso, los contenedores tienen aún más ventajas que la virtualización en lo que respecta a la eficiencia del centro de datos.
• Despliegue y gestión automatizados. La naturaleza estandarizada de los contenedores significa que las empresas pueden desplegar y gestionar dinámicamente aplicaciones en contenedores. Es lo que se denomina orquestación de contenedores. Herramientas de orquestación como Kubernetes automatizan el despliegue y la supervisión de aplicaciones a gran escala.

La contenedorización amplía y potencia las ventajas de la virtualización. Los usuarios empresariales obtienen niveles sin precedentes de escalabilidad y capacidad de gestión cuando las aplicaciones se despliegan a través de contenedores estandarizados.

La relación entre los contenedores y el host

La contenedorización ofrece ventajas significativas, sobre todo cuando se trata de aplicaciones empresariales a gran escala.

Sin embargo, los contenedores suponen un cambio radical en la forma en que se despliegan las aplicaciones y, desde un punto de vista práctico y de seguridad, es útil tener una visión de la relación entre un contenedor y su host.

Si bien es cierto que los contenedores se ejecutan de forma aislada, es importante entender que los contenedores también comparten componentes. De este modo se elimina la sobrecarga de ejecutar un sistema operativo distinto para cada aplicación de un contenedor.

También significa que los contenedores se ponen en marcha más rápidamente que un sistema operativo completo. Entonces, ¿qué elementos del host comparten los contenedores? El núcleo del sistema operativo es el aspecto compartido más importante: sólo hay un núcleo en ejecución en el host y todos los contenedores del host comparten este núcleo.

A continuación, los contenedores comparten los controladores y los binarios de las aplicaciones del SO, mientras que los contenedores también comparten el almacenamiento del SO anfitrión, aunque el almacenamiento está aislado. Por último, los contenedores también comparten la plataforma de contenedores, como Docker, por ejemplo.

La capacidad de los contenedores para ejecutarse de forma aislada se debe a algunas características básicas de Linux que utilizan las plataformas de contenedores (por ejemplo, Docker) para reforzar el aislamiento. Los espacios de nombres del kernel y los cgroups facilitan que contenedores independientes compartan el mismo host Linux.

Aislada, sí, pero aún vulnerable

Está claro que los contenedores ofrecen un alto nivel de aislamiento, lo que a su vez proporciona cierto grado de protección: las amenazas no pueden propagarse de una aplicación a otra con tanta facilidad.

Sin embargo, debido a la compartición de recursos inherente a las cargas de trabajo en contenedores, estos siguen siendo vulnerables y, de hecho, pueden introducir nuevas vulnerabilidades que las organizaciones deben tener en cuenta. Veamos algunos ejemplos:

• Seguridad de las imágenes. Es fundamental asegurarse de que sólo se ejecutan imágenes de contenedores procedentes de una fuente de confianza. Tanto una imagen envenenada como una imagen sin parches pueden abrir la puerta a ataques. La seguridad de las imágenes es realmente importante.
• Seguridad de la plataforma de contenedores. Al igual que cualquier otro software, su plataforma de contenedores puede contener riesgos de seguridad. Considere, por ejemplo, la vulnerabilidad de ejecución remota de acceso root runCinherente a las bibliotecas runC que suelen utilizar los proveedores de software de contenedores.
• Riesgo de escalada de privilegios. Aunque en teoría las aplicaciones no deberían salirse de los contenedores, merece la pena tener mucho cuidado con los privilegios de usuario que se utilizan en un contenedor. Si una aplicación de contenedor tiene acceso root por cualquier razón, existe el riesgo de que una fuga le dé al atacante acceso root a toda la máquina. El riesgo runC descrito en el punto anterior es típico de un riesgo de seguridad de fuga.

Así pues, aunque las aplicaciones están aisladas, el mecanismo de aislamiento -los contenedores- conlleva sus propios riesgos de seguridad y las empresas deben gestionar sus cargas de trabajo en contenedores de forma que se mitiguen estos riesgos de seguridad.

Kernels sin parches: ¿Un riesgo oculto para la seguridad de los contenedores?

Los componentes compartidos de los contenedores conllevan claramente riesgos de seguridad. Pero podría decirse que el mayor riesgo para la seguridad de las aplicaciones en contenedores es el núcleo compartido del sistema operativo. Los riesgos de seguridad planteados por el kernel del host se ocultan esencialmente a plena vista.

Recuerde: todos los contenedores de un host comparten el mismo núcleo del sistema operativo. Existe el riesgo de que las organizaciones malinterpreten el aislamiento y, por tanto, las ventajas de seguridad de la contenedorización al no tener en cuenta los riesgos que plantea un núcleo de sistema operativo compartido.

Sin embargo, una vez que el núcleo del sistema operativo se ve comprometido, la aplicación dentro del contenedor también puede verse comprometida. Y sabemos que los kernels de los sistemas operativos tienen un largo historial de violaciones de seguridad de todo tipo y tamaño.

Por eso la seguridad del núcleo es tan importante cuando se trata de proteger las cargas de trabajo en contenedores. Hay algunas cosas que puedes hacer para garantizar un kernel seguro para tu carga de trabajo en contenedores: estar al tanto de los últimos riesgos de seguridad del kernel y asegurarte de que tu kernel Linux solo contiene los servicios que necesitas para las cargas de trabajo en contenedores.

No te olvides, por supuesto, de los parches del kernel.

El problema de parchear los núcleos

El núcleo de Linux se parchea continuamente. A medida que surgen vulnerabilidades, la comunidad ajusta el código del núcleo de Linux para combatirlas y publica un parche. Los sistemas sin parches están en peligro, los parcheados no.

Parchear debería ser una obviedad: es una medida de seguridad sencilla que aumenta significativamente la seguridad de los contenedores. Sin embargo, parchear de forma coherente puede ser muy difícil:

• Laaplicación de parches lleva mucho tiempo. Dado el volumen de parches del kernel de Linux que se publican, muchas organizaciones pueden tener dificultades para mantenerse a la vanguardia de la aplicación de parches, sobre todo en grandes parques tecnológicos con miles de máquinas.
• Laaplicación constante de parches es cara. A menos que esté automatizado, el despliegue de parches puede agotar los recursos incluso de los mejores equipos técnicos. La aplicación de parches se convierte en un proceso costoso y un objetivo fácil para el ahorro y la reducción de costes.
• Losparches son perjudiciales. Un parche del kernel a menudo requiere reiniciar el servidor. Para muchas cargas de trabajo, un reinicio será muy perjudicial. Reiniciar un contenedor puede ser muy rápido, pero reiniciar todo el host puede provocar una interrupción notable del servicio. Como resultado, los parches suelen retrasarse.

Claramente, uno de los mayores riesgos de seguridad para las cargas de trabajo en contenedores es, de hecho, muy difícil de gestionar de forma coherente.

Integración de KernelCare Live Patching

La automatización de la aplicación de parches es el primer paso para reducir con éxito los riesgos de vulnerabilidades del núcleo en cargas de trabajo en contenedores. Otro paso fundamental es la aplicación de parches en tiempo real: la capacidad de actualizar el núcleo del sistema operativo sin necesidad de reiniciar el servidor. KernelCare live patching ofrece ambas cosas.

Las empresas que gestionan cargas de trabajo en contenedores pueden utilizar KernelCare para asegurarse de que los kernels de sus hosts contenedores están parcheados de forma constante, y parcheados sin interrupciones. Es muy sencillo: basta con instalar KernelCare de la forma habitual.

Al instalar KernelCare para parchear sus hosts de contenedores, también disfrutará, por consiguiente, de un parcheado totalmente automatizado del kernel utilizado por los contenedores. Dado que los contenedores comparten el kernel del host, solo tiene que instalar KernelCare en su host de contenedores una vez, y las actualizaciones del kernel se aplicarán a todos los contenedores de ese host.

En resumen, KernelCare es una forma eficaz y práctica de gestionar uno de los mayores riesgos de seguridad asociados a la contenedorización.

Otros consejos para la seguridad del núcleo del contenedor

Antes de concluir el artículo, tocaremos algunos otros puntos que merece la pena tener en cuenta a la hora de mantener seguro el kernel de tu host contenedor. Sí, la aplicación de parches es fundamental, pero también debes tener en cuenta los siguientes puntos, la mayoría de los cuales son simplemente buenas prácticas para la seguridad del servidor:

• Eliminar el usuario root. Al restringir el usuario root puede asegurarse de que un contenedor que rompa el aislamiento no obtenga automáticamente acceso root a todo el servidor.
• Limita los módulos del kernel que ejecutas. Cuando configure un servidor, puede ampliarlo añadiendo módulos del núcleo. Para obtener la máxima seguridad, te sugerimos que instales la cantidad mínima de módulos del kernel que necesites para tu entorno de contenedores, pero asegúrate de mantener los módulos críticos que refuerzan la seguridad a través de roles y permisos.
• Utilice herramientas de seguridad para contenedores. Hay herramientas desarrolladas específicamente para escanear la configuración de tu contenedor y compararla con las mejores prácticas. docker-bench-security es un ejemplo, comprueba docenas de puntos en tu configuración y la evalúa según las reglas de las mejores prácticas.

Como siempre, una seguridad completa requiere una cuidadosa configuración del servidor y una gestión proactiva y continua del mismo.

Conclusión

La contenedorización está transformando las cargas de trabajo de las aplicaciones empresariales al reducir el coste de la infraestructura, acelerar el proceso de despliegue de aplicaciones e introducir una flexibilidad y escalabilidad sin precedentes.

Sin embargo, la ejecución de aplicaciones dentro de contenedores también conlleva riesgos de seguridad únicos que pueden no ser evidentes a primera vista. La seguridad del kernel y la aplicación de parches es un área crítica que debe tratarse con sumo cuidado.

KernelCare ofrece a su organización la posibilidad de actualizar automáticamente los kernels que soportan sus cargas de trabajo en contenedores, y de hacerlo sin las interrupciones y el tiempo de inactividad asociados a los reinicios del sistema.