Cómo diseñar la arquitectura de Kubernetes más segura
Los entornos Kubernetes tienen muchas formas y tamaños. De forma inherente, algunos son más seguros que otros.
En otras palabras, la arquitectura de Kubernetes (la estrategia arquitectónica elegida al diseñar el entorno de Kubernetes) puede tener importantes implicaciones para la seguridad general. Un entorno de varios clústeres puede ser más seguro en ciertos aspectos que otro que ejecute todo en un solo clúster (pese a que múltiples clústeres también aumentan la complejidad, lo cual supone una desventaja desde el punto de vista de la seguridad). Igualmente, existen implicaciones de seguridad para las herramientas de terceros, como los agentes de monitorización y las mallas de servicios, que se decidan integrar en la arquitectura de Kubernetes.
Entonces, ¿qué tipos de estrategias arquitectónicas ayudan a conseguir la postura de seguridad más sólida para el entorno de Kubernetes? En este artículo ofrecemos una respuesta a esa pregunta repasando las opciones de diseño de alto nivel que los administradores normalmente adoptan al planificar un entorno de Kubernetes y analizando lo que significa cada elemento desde el punto de vista de la seguridad.
Servicio gestionado de Kubernetes y Kubernetes autogestionado
Probablemente, la primera pregunta que se plantean hoy en día la mayoría de los equipos al planificar una instalación de Kubernetes es si utilizar un servicio gestionado de Kubernetes como Amazon AKS, Azure Kubernetes Service u otra plataforma de Kubernetes que se ejecute en una nube pública, o desplegar y gestionar ellos mismos Kubernetes en la infraestructura que controlan.
Un servicio gestionado de Kubernetes suele casi siempre más fácil de configurar y mantener, ya que el proveedor de Kubernetes al menos se encarga de algunas de las tareas de aprovisionamiento y mantenimiento necesarias para mantener los clústeres en funcionamiento. (Tenga en cuenta que el alcance de las funciones de gestión que ofrecen los proveedores puede variar significativamente de un servicio “gestionado” de Kubernetes a otro, pero eso es tangencial al tema que nos ocupa aquí).
Kubernetes gestionado también puede ser más seguro en dos aspectos clave:
- La arquitectura de host se gestiona de manera profesional y se monitoriza para detectar amenazas de seguridad. Es decir, con Kubernetes gestionado no es necesario preocuparse tanto por los problemas de seguridad a nivel de OS en los nodos.
- Su proveedor de Kubernetes gestionado puede proporcionar ajustes preconfigurados o herramientas que (en la mayoría de los casos, al menos) observen las prácticas recomendadas de seguridad.
Por otro lado, dado que la arquitectura de Kubernetes gestionado implica el uso de herramientas y (en la mayoría de los casos) infraestructura que es propiedad de un proveedor, tiene el inconveniente en cuanto a la seguridad inherente de que restringe la cantidad de control y privacidad que los usuarios pueden lograr. No se puede utilizar un servicio gestionado de Kubernetes si lo que se desea es “aislar” los clústeres desde Internet, por ejemplo. Y si bien algunos tipos de plataformas Kubernetes gestionado (como Platform9) son compatibles con la infraestructura local, la mayoría requiere el uso de infraestructura alojada en la nube pública, que está más expuesta a amenazas de seguridad.
En conclusión: si no tiene experiencia con Kubernetes y no conoce bien los principios de seguridad de Kubernetes, un servicio gestionado de Kubernetes probablemente proporcionará un entorno más seguro que uno que configure usted mismo. Pero si lo que necesita es una arquitectura de seguridad avanzada que incluya funciones como el aislamiento físico o “air-gapping”, tendrá que configurar y gestionar tu entorno por su cuenta.
Arquitectura de Kubernetes con un solo clúster o multiclúster
Otra decisión arquitectónica clave que hay que tomar al planificar una instalación de Kubernetes es si se va a configurar un solo clúster o varios clústeres.
Tradicionalmente, casi todos los equipos utilizaban un solo clúster. No obstante, los entornos multiclúster son cada vez más populares según la CNCF, en parte porque permiten alcanzar un alto grado de aislamiento entre workloads. Pueden desplegarse workloads diferentes en distintos clústeres, lo que reduce notablemente el riesgo de que un problema de seguridad en una workload se “extienda” y afecte a otras. Lea más sobre cómo proteger los clústeres de Kubernetes.
Dicho esto, los equipos deben sopesar esta ventaja en materia de seguridad frente al principal inconveniente de Kubernetes multiclúster: la complejidad añadida. Un mayor número de clústeres significa, entre otras cosas, más registros de auditoría que controlar, más políticas RBAC que crear, aplicar y supervisar, y más redes que configurar y aislar.
Si cuenta con automatizaciones sólidas para gestionar y monitorizar sus clústeres, puede que esta complejidad no suponga un gran problema. Si es así, opte por una arquitectura multiclúster. Pero si va a tener dificultades para mantener un seguimiento de todo con ese tipo de configuración, decántese por un solo clúster, ya que le será más fácil gestionar tareas como la detección de eventos de seguridad y asegurar que las políticas RBAC se mantengan actualizadas.
Un namespace vs. múltiples namespaces
Incluso si no ejecuta varios clústeres, puede lograr un buen aislamiento de la workload mediante la creación de varios namespaces. Básicamente, los namespaces son clústeres virtuales que se alojan dentro del mismo clúster físico.
Lo normal es crear un namespace diferente para cada aplicación que ejecute en Kubernetes. Asimismo, se deberían crear diferentes namespaces para desarrollo, pruebas y producción.
No obstante, recuerde que el aislamiento que proporcionan los namespaces es limitado. Cualquier permiso que se asigne a través de ClusterRoles se aplicará a todos los namespaces. En este sentido, tener varios namespaces solo resulta útil si se crean políticas RBAC que permitan aislar a los usuarios y las cuentas dentro de cada namespace. Para ello, siempre que sea posible, asigne los permisos utilizando Roles en lugar de ClusterRoles.
Mallas de servicios
Las mallas de servicios, que gestionan el descubrimiento de servicios y la conectividad de los recursos que se ejecutan dentro de un clúster de Kubernetes, son una herramienta fundamental para cualquier entorno de Kubernetes que incluya más que unos pocos servicios.
En general, las mallas de servicios son positivas para la seguridad de Kubernetes. Además de ayudar a gestionar la conectividad, la mayoría de las mallas de servicios también ofrecen funciones de monitorización y alerta que pueden ayudarle a detectar amenazas a la seguridad. Teniendo en cuenta que Kubernetes no registra por sí mismo los incidentes de seguridad relacionados con la red (los eventos de auditoría de Kubernetes no cubren la red, solo la API), las mallas de servicio cierran una brecha crítica de visibilidad.
El inconveniente de las mallas de servicios es que aumentan la superficie de ataque general y la complejidad de Kubernetes. Un atacante que logre vulnerar su malla de servicios puede utilizarla como posición fuerte para acceder a todo su clúster (o clústeres).
Sin embargo, siempre y cuando que se desplieguen las mallas de servicios de forma segura, se pueden mitigar los riesgos asociados. Si despliega su software de malla de servicios a través de containers sidecar que se ejecuten junto a sus pods de la aplicación, asegúrese de aislar los sidecars y bloquear su acceso utilizando RBAC y políticas de red.
Monitorización externa y software de seguridad
Además de las mallas de servicios, es habitual que los equipos desplieguen software de terceros para monitorear el rendimiento y la seguridad y les ayude a gestionar sus clústeres.
Estas herramientas también aumentan la superficie de ataque. Pero si se despliegan de forma segura, los beneficios superan con creces los riesgos.
Puede optimizar la seguridad de las herramientas externas siguiendo las siguientes prácticas:
- Como se indicó anteriormente, aplique el mínimo privilegio para los agentes que se ejecutan como containers sidecar.
- Cuando sea posible, utilice webhooks para transmitir datos desde Kubernetes a las herramientas externas. De este modo, evitará tener que ejecutar las herramientas directamente dentro de su clúster, lo cual supone un mayor riesgo de seguridad que ejecutarlas de forma aislada.
- Asegúrese de proteger cualquier dato que las herramientas externas generen o almacenen de forma persistente. Este tipo de información que se encuentra en los registros de auditoría de Kubernetes podría ayudar a los atacantes a acceder a su clúster, por lo que debe ser cuidadoso con la gestión de esos datos.
Diseño de la arquitectura de Kubernetes más segura
En última instancia, no existe un enfoque único para diseñar una arquitectura Kubernetes segura. Las decisiones que atañen a la arquitectura suelen reflejar la escala del entorno, los tipos de workloads que se ejecutan en él y la cantidad de usuarios o equipos diferentes que comparten el entorno. Lo más probable es que los entornos más pequeños tengan un diseño más sencillo y requieran menos herramientas externas, lo que se traduce en una postura de seguridad más sólida por defecto.
Con todo, los entornos complejos, es decir, aquellos que incluyen múltiples clústeres y diversas integraciones de terceros, pueden ser tan seguros como las configuraciones de arquitectura más sencilla.
Por lo tanto, la clave para diseñar un entorno de Kubernetes seguro no está en evitar un determinado tipo de configuración o asegurarse de incluir o no una determinada herramienta. Simplemente hay que asegurarse de que cada vez que se aumente la complejidad arquitectónica de Kubernetes, se identifiquen y aborden las implicaciones de seguridad que ello conlleva.