En esta tercera parte de la serie sobre seguridad en Kubernetes, exploraremos el modelo de seguridad en capas (4Cs), que protege Kubernetes en cuatro niveles: cloud, clúster, contenedores y código. En la primera parte de la serie introdujimos al modelo y su importancia. Luego, en la segunda parte, aprendimos cómo proteger la capa cloud.
Esta vez hablaremos de la capa de clúster y los controles de seguridad para protegernos de ataques en Kubernetes. La capa de clúster es crucial ya que abstrae el hardware y permite que las aplicaciones se ejecuten en un entorno virtualizado. Las medidas a presentar pueden variar según el modelo de despliegue de Kubernetes.
a) De forma manejada por algún servicio en la nube pública como EKS, AKS, o GKE
b) Sobre maquinas virtuales de servicios de nube o sobre servidores on-premise administrados directamente por nosotros
Si usas un proveedor de servicios en la nube, este se encargará de varios aspectos de seguridad o los ofrecerá de forma predeterminada. Sin embargo, en esta guía asumiremos que estás utilizando un enfoque más genérico para entender todos los aspectos de seguridad necesarios para proteger tu clúster, incluso si alguien más lo configura por ti.
Existen varias prácticas recomendadas que puedes seguir para asegurarte de que tu capa de clúster esté protegida. Estas son las principales:
Desde el API de Kubernetes, se pueden ver, crear, modificar o eliminar recursos del clúster, como nodos, pods, servicios, secrets, entre otros. Por esto, es de vital importancia aplicar medidas de control de acceso al mismo, como la autenticación y autorización.
La autenticación es el proceso de verificar la identidad del usuario o entidad que intenta acceder a un sistema o recurso. Para esto, en Kubernetes se pueden usar distintos métodos, como Certificados TLS, Bearer Tokens, Basic Auth o Proxy de autenticación. Puedes revisar estrategias de autenticación en la documentación oficial para obtener una guía paso a paso y ejemplos de cada uno de estos métodos.
La autorización, por otro lado, es el proceso de determinar si un usuario o entidad autenticada tiene los permisos adecuados para acceder a un recurso específico. En línea con esto, se deben establecer mecanismos que evalúen cada petición al API contra una serie de reglas establecidas para establecer si se permiten o se niegan. La documentación oficial de Kubernetes recomienda el uso de:
Además, se deben deshabilitar algunas configuraciones predeterminadas de Kubernetes, como el acceso anónimo al servidor API, controlar el uso de personificación y establecer controles de admisión a las peticiones.
Los Kubelets exponen endpoints HTTPS que otorgan un amplio control sobre el nodo donde se ejecutan y sus contenedores. Por defecto, los Kubelets permiten el acceso no autenticado a esta API. Para evitar que un actor malintencionado pueda realizar modificaciones en nuestros pods o imágenes que ejecutan nuestra aplicación, los clústeres de producción deben habilitar la autenticación y autorización de Kubelet.
Si quieres prevenir el acceso no autenticado al API, debes iniciar el kubelet con el siguiente flag: --anonymous-auth=false. Si deseas habilitar la autorización sobre el kubelet, puedes usar los flags --authorization-mode=Webhook y --kubeconfig.
Puedes encontrar más detalles en la documentación de autenticación y autorización de Kubelet.
Diferentes políticas deben ser establecidas según los siguientes niveles:
De manera predeterminada todos los pods de un clúster de Kubernetes se pueden comunicar entre sí, esto debe ser cambiado según el caso de uso especifico y permitir conexiones solo entre pods que lo requieran. Adicionalmente, se deben configurar políticas de Firewall para restringir las peticiones de red externas a las mínimas necesarias para el correcto funcionamiento de las aplicaciones que se corran.
Las políticas de red se configuran a través de un API que Kubernetes dispone para ello; la comunicación con esta API usualmente la hace un proveedor o plugin externo, siendo Calico uno de los más usados. Puedes aprender más a configurarlas con la guía de Declara una Política de Red.
Se deben definir contextos de seguridad para los contenedores corriendo dentro de cada pod. Cuando sea posible, los contenedores deben correr sin privilegios de root dentro del pod y herramientas que implementen MAC (Mandatory Access Control) -las cuales niegan todo de forma predeterminada y enforzan el acceso a ciertos recursos del sistema basado en una serie de reglas definifas- como AppArmor o SELinux deben ser usadas.
Puedes aprender más sobre esto en la guía de Estándares de Seguridad de Pod o la de Configuración de un Contexto de Seguridad para un Pod o Contenedor que incluye diferentes niveles de políticas según qué tan restrictivos queramos ser.
Kubernetes incluye herramientas que permiten llevar logs detallados de las aplicaciones, los contenedores dentro de cada pod y los clústeres activos. Estos deben ser activados debido a que no se realiza de manera predeterminada. Para que esto sea efectivo, se debe crear una política de monitoreo de logs de manera regular de tal manera que un comportamiento extraño pueda ser descubierto a tiempo. Algunas de las herramientas más conocidas son:
Etcd es la base de datos interna usada por cada clúster de Kubernetes, allí se guarda información sensible como nombres de usuario de bases de datos, contraseñas, y consultas. Se recomienda aislar etcd tras un firewall para evitar que se pueda tener acceso a esta por medio de la API. Puedes habilitar la encripción en reposo de los datos siguiendo la guía de Encriptar Datos Secretos en Reposo.
Aunque Kubernetes encripta etcd, su llave de encripción se guarda como un texto plano en el nodo máster, por esto, se recomienda adicionalmente usar herramientas de manejo de secretos como Vault.
Dado que nuevos ataques y vulnerabilidades se van descubriendo en las herramientas de Kubernetes, es de vital importancia que se mantengan actualizados todos los componentes del clúster de manera continua y tan pronto como aplicar las actualizaciones sea posible sin disrumpir el funcionamiento de las aplicaciones.
Kubernetes maneja un ciclo de actualizaciones donde realiza 3 lanzamientos de nuevas versiones al año y donde cada versión tiene soporte por 8 meses posterior a su lanzamiento.
En adición, puedes unirte al grupo kubernetes-announce para recibir correos electrónicos sobre anuncios de seguridad.
Para evitar ataques de denegación de servicios (DOS), es importante limitar el uso de CPU y memoria de los contenedores. Esto se puede hacer a través de CGroups en el Kernel de Linux o configurando ResourceQuota en Kubernetes. Puedes aprender más en la documentación de Cuotas de Recursos.
En adición, Kubernetes permite configurar el número máximo de instancias para un contenedor y el número máximo de contenedores corriendo en un pod. Esto lo puedes ver a más detalle en la guía de Configurar Peticiones Predeterminadas de Memoria y Limites para un Namespace.
Se recomienda la configuración de certificados TLS para asegurar que una comunicación encriptada entre los componentes de Kubernetes como el servidor API, etcd, Kubelet y Kubectl. Una ventaja es que Kubernetes espera que toda la comunicación de la API en el clúster esté cifrada de forma predeterminada con TLS, y la mayoría de los métodos de instalación permitirán que los certificados necesarios sean creados y distribuidos a los componentes del clúster.
Kubernetes genera metadatos que incluye información que, aunque en primera instancia no pueda parecer importante, en manos de un atacante experto puede ser usada para buscar fallas en las versiones de las herramientas o SO que se manejen en los distintos componentes del clúster de Kubernetes.
Debido a esto, el acceso a esta información debe ser restringido solo a usuarios autorizados. Esto se puede hacer mediante el uso de RBAC asignando RoleBindings de roles que tengan acceso a los endpoints de la API de Kubernetes que tengan esta información solo a ciertos usuarios de confianza.
Si por otro lado, tu clúster vive en un servicio manejado por alguna plataformas en la nube (AWS, Azure, GCE, etc.) a menudo exponen servicios de metadatos localmente a las instancias. Por defecto, estas APIs son accesibles por los pods que se ejecutan en una instancia y pueden contener credenciales de nube para esa instancia, o datos de aprovisionamiento, como credenciales de kubelet.
Estas credenciales pueden ser utilizadas para escalar dentro del clúster o para acceder a otros servicios de la nube bajo la misma cuenta. Por esto, se debe restringir los permisos de las credenciales que viven en las instancias al igual que establecer politicas de rotación continua de las credenciales para dificultar a los atacantes su uso en caso de que lleguen a obtenerlas.
En caso de que sea necesario, aplicaciones que manejen información o procesos considerados como sensibles deben ser desplegados en un set de máquinas o ambientes específicos separados del resto de aplicaciones. De esta forma, en caso de una brecha de seguridad, los atacantes no podrán tener acceso a estas aplicaciones.
Siguiendo estas prácticas recomendadas, puedes ayudar a asegurar que tu capa de clúster esté protegida y a salvo de posibles amenazas.
Cómo proteger tus aplicaciones en Kubernetes fue la primera entrada de esta serie de blogs sobre seguridad en Kubernetes. Allí exploramos en un alto nivel las 4Cs de la seguridad de K8s y ahora aprendimos con mayor detalle cómo proteger la primera capa del modelo de seguridad.
La segunda entrega fue Protege la capa de nube de Kubernetes: 8 consejos clave. Allí vimos en detalle 8 pasos que puedes realizar para proteger tu nube o infraestructura. Espera en siguientes entradas recomendaciones sobre cómo proteger las capas de Contenedores y Código.
De igual forma, te vuelvo a invitar a que conozcas nuestro curso de Kubernetes. Donde aprenderás los principales aspectos sobre Kubernetes. Al igual que siempre es recomendado revisar la documentación oficial de K8s sobre seguridad para aprender todos los conceptos a mayor profundidad.
Por último, me gustaría oír de ti. Puedes dejar en los comentarios ¿qué otras prácticas has implementado para proteger tu clúster de Kubernetes? O si hay algún tema especifico del cual te gustaría que hablara en las siguientes entradas de esta serie de blogs, igual eres bienvenido a dejarlo en los comentarios.
