Diseño de una estrategia segura de orquestación de containers y arquitectura en containers
Si trabaja con containers, probablemente sepa que la orquestación es esencial para gestionar workloads complejas en containers a escala.
Pero la orquestación de containers no se limita a la gestión de los mismos. También tiene implicaciones decisivas para la seguridad de los containers. Mediante la definición de su arquitectura en containers y la forma en que estos interactúan entre sí, su enfoque de la orquestación de containers ayuda a determinar el grado de seguridad de su entorno por defecto y la probabilidad de que una brecha pueda propagarse desde un container a todo el clúster.
Por este motivo, la planificación de una estrategia de orquestación de containers segura y la integración de la seguridad en su arquitectura basada en containers es un componente clave para la seguridad general de estos. En este artículo explicamos cómo proteger los containers a nivel de orquestación y arquitectura.
Definición de la orquestación de containers
La orquestación de containers es el uso de herramientas automatizadas para gestionar las operaciones necesarias para ejecutar containers.
Las plataformas de orquestación de containers, como Kubernetes, Amazon ECS y Docker Swarm, asumen automáticamente tareas como, por ejemplo, decidir qué nodos de un clúster de servidores deben alojar un determinado container o reiniciar los containers si estos se bloquean o dejan de responder. Puesto que este trabajo llevaría mucho tiempo si se llevara a cabo manualmente, la orquestación de containers hace que resulte práctico desplegar entornos en containers a gran escala que incluyan docenas, cientos o incluso miles de containers repartidos en un gran número de nodos.
Orquestación y seguridad de containers
El objetivo principal de la orquestación de containers no es asegurar los containers, ni tampoco las plataformas de orquestación de containers son plataformas de seguridad. La mayoría de los requisitos de seguridad de un entorno en containers son gestionados por herramientas externas que monitorizan, detectan y ayudan a solucionar las amenazas.
No obstante, el enfoque que adopte para la orquestación y la plataforma de orquestación que elija ayudan a definir la postura general de seguridad de los containers.
Esto se debe a que la estrategia de orquestación de containers desempeña un papel muy importante a la hora de definir cómo se configura su entorno de containers y qué tipo de arquitectura utiliza para enviarlos, desplegarlos y gestionarlos. Algunas estrategias de orquestación y arquitecturas basadas en containers son más seguras que otras, dependiendo de factores como el grado de aislamiento de los containers y las herramientas que se utilicen para aplicar los requisitos de seguridad y gobernanza al gestionar las operaciones de containers.
Cómo crear una arquitectura segura basada en containers
A la hora de planificar una estrategia de orquestación y diseñar la arquitectura de su entorno, debe tener en cuenta varias consideraciones importantes relativas a la seguridad.
Aislamiento de containers
El factor más importante que hay que evaluar es cuál es la medida de aislamiento que su arquitectura y orquestador proporcionan a los containers individuales.
En general, tendrá que encontrar un equilibrio entre un exceso de aislamiento y un aislamiento insuficiente. Si los containers no son capaces de compartir datos con otros a través de la red, de acceder a los mismos volúmenes de almacenamiento de datos y de interactuar de otras maneras, es probable que le resulte muy difícil desplegar una aplicación viable utilizando containers. Esto es especialmente válido si su aplicación utiliza una arquitectura de microservicios en la que cada microservicio se despliega en su propio conjunto de containers y necesita comunicarse con otros containers para que la aplicación funcione.
También puede que le resulte difícil realizar tareas como la monitorización si su arquitectura en containers aplica demasiado aislamiento. En muchos casos, las herramientas de monitorización para entornos en containers se basan en una arquitectura “sidecar” en la que un container que aloja un agente de monitorización se ejecuta junto a los containers de la aplicación que debe monitorizar. Si el agente de monitorización no puede comunicarse con los otros containers, no podrá recopilar los registros y las métricas que necesita para monitorizar correctamente.
Por otro lado, un aislamiento insuficiente entre containers es una invitación a que surjan problemas de seguridad. Aunque asignar excesivos permisos a cada container no será la causa principal de una brecha de seguridad, sí que puede agravar en gran medida las brechas que se producen debido a, por ejemplo, vulnerabilidades en una imagen de container, o bien a causa de un tiempo de ejecución de container u OS anfitrión inseguros. Estos riesgos se pueden evitar utilizando controles como los contextos de seguridad de Kubernetes, que limitan las acciones que los containers pueden realizar.
Para encontrar el punto medio entre un aislamiento excesivo o insuficiente, aplique el principio del mínimo privilegio a sus containers. Asegúrese de que los containers pueden acceder a los recursos externos que necesitan para cumplir su función dentro del entorno, pero a nada más. Asegúrese también de que los permisos se definen de forma granular y no caiga en la tentación de aplicar contextos de seguridad genéricos a todo un namespace o (lo que es peor) a un clúster. Los permisos granulares precisan más trabajo de configuración y gestión, pero mejoran la seguridad general.
Tiempos de ejecución de containers
El tiempo de ejecución de un container es el software que ejecuta los containers individuales. Existen muchos tiempos de ejecución, como containerd y runC. Todos ellos ejecutan containers, pero cada uno lo hace de manera ligeramente diferente.
Puesto que no todos los orquestadores admiten todos los tiempos de ejecución, la solución de orquestación que usted elija definirá qué tiempo de ejecución de containers (o tiempos de ejecución) puede utilizar para desplegar containers. Por ejemplo, Kubernetes admite la mayoría de los principales tiempos de ejecución de containers, mientras que Amazon ECS solo admite el tiempo de ejecución propio de Amazon.
En general, ningún tiempo de ejecución de containers es más seguro que los demás. Todos los principales tiempos de ejecución de containers han tenido importantes vulnerabilidades de seguridad.
Sin embargo, hay algunos proyectos, como Kata Containers, cuyo objetivo es crear tiempos de ejecución que sean intrínsecamente más seguros haciendo cambios en la propia arquitectura del tiempo de ejecución. En el caso de Kata, por ejemplo, los containers no comparten un núcleo, lo que reduce significativamente el riesgo de ataques de escalada de privilegios y controles de acceso inseguros.
Si elige una estrategia de orquestación de containers y una arquitectura general en containers que le permita aprovechar los tiempos de ejecución en función de la seguridad, puede obtener algunas ventajas de seguridad que no están disponibles actualmente en los tiempos de ejecución estándar.
Compatibilidad del sistema operativo
Actualmente, la gran mayoría de los containers se ejecutan en Linux, y normalmente no importa qué distribución de Linux se utilice para alojar containers. Los containers se comportan de la misma manera independientemente de la versión de OS Linux o de la configuración que los aloja.
Pero también hay containers de Windows para los equipos que quieren desplegar aplicaciones en containers en este sistema operativo.
El grado de compatibilidad con Windows varía entre las diferentes soluciones de orquestación. Por ejemplo, Kubernetes es capaz de gestionar sistemas Windows como nodos de trabajo, pero no como nodos maestros. Eso significa que si bien se pueden orquestar containers de Windows con Kubernetes, será necesario seguir utilizando herramientas basadas en Linux para ayudar a gestionarlos. En cambio, Docker Swarm ofrece una compatibilidad bastante completa con los containers de Windows.
¿Qué tiene que ver la compatibilidad del sistema operativo con la seguridad de los containers? Es verdad que no mucho, aunque se puede argumentar que el despliegue de containers de Windows puede resultar más seguro que el de containers de Linux. Esto se debe a que los containers de Windows son mucho menos populares y, por ello, un objetivo menos frecuente para los atacantes. (No deja de resultar irónico que ocurra todo lo contrario cuando se trata de software de escritorio, en cuyo caso Linux es un objetivo mucho menos frecuente que Windows, pero la mayoría de los containers están diseñados para alojar workloads en el servidor en lugar de aplicaciones de escritorio).
Por lo tanto, si busca una estrategia de seguridad lista para usar, considere la posibilidad de crear una arquitectura de containers que le permita utilizar containers de Windows.
Plugins de terceros
Otra cuestión importante a considerar a la hora de diseñar una arquitectura de containers segura es la cantidad de plugins de terceros que serán necesarios para crear el entorno completo.
Algunos orquestadores, como Kubernetes, están diseñados para ser altamente modulares. Kubernetes suele aprovechar plugins de proyectos de terceros para habilitar la gestión de datos o la gestión de la red.
Otros orquestadores, como Amazon ECS, adoptan una arquitectura menos modular. Estos le ofrecen un conjunto de herramientas integradas y poca capacidad para cambiar a soluciones alternativas.
Desde el punto de vista de la seguridad, los plugins de terceros comportan tanto ventajas como inconvenientes. Por un lado, un buen plugin de terceros puede ofrecerle mejor monitorización y visibilidad de la seguridad que las herramientas nativas del orquestador.
Por otro lado, depender de muchos módulos de terceros suele traducirse en más riesgos potenciales para la seguridad y en un mayor número de vulnerabilidades que hay que rastrear y gestionar. Si utiliza solamente las herramientas nativas de su orquestador, el único riesgo que corre son las vulnerabilidades asociadas a dichas herramientas. En el caso de que implemente Kubernetes con una larga lista de plugins externos, tendrá que gestionar los riesgos de seguridad de cada uno de los plugins, además de proteger Kubernetes.
En general, las ventajas de una arquitectura modular probablemente superen a los riesgos. Pero si prefiere la simplicidad, elija un orquestador menos modular.
Diseñar una arquitectura en containers y una estrategia de orquestación que sea segura por defecto no significa que vaya a ser inmune a las amenazas. Todavía es posible que se cuelen algunos riesgos en su entorno a través de imágenes contaminadas, exploits en el OS u otras amenazas similares. A pesar de todo, una arquitectura y un orquestador seguros le permitirán aislar y solucionar eficazmente las amenazas cuando aparezcan.