Guía de Modelos de Amenazas para Kubernetes

por Brandon Niemczyk (Cloud Security Research Lead) 

 

Kubernetes es uno de los sistemas de orquestación de containers más utilizados en ambientes en la nube. Como tal, como cualquier aplicación de uso común, es un blanco atractivo para los cibercriminales y otros actores maliciosos. Hay tres áreas generales que los administradores de la nube deben proteger, ya que estas pueden introducir riesgos o amenazas a sus estrategias de contenerización potenciadas por Kubernetes. 

 

• Ataques externos: ataques provenientes desde fuera de la organización (cualquier ataque no autenticado cae en esta categoría)

• Temas de configuración: problemas derivados de configuraciones inseguras

• Aplicaciones vulnerables: problemas derivados de vulnerabilidades en el software o en aplicaciones 

 

Ataques externos 

 

La figura 1 muestra los componentes de un despliegue de Kubernetes, o cluster, como lo documenta Kubernetes. 

 

[image url=”http://blog.la.trendmicro.com/wp-content/uploads/2020/06/tm_blog_kubernets_fig1.png” raw=”true” alignment=”center” margin_left=”0″ margin_right=”0″ margin_top=”0″ margin_bottom=”0″]

Figura 1. Diagrama de componente de Kubernetes 

 

Todas las comunicaciones se reúnen a través de kube-api-server, el cual es un componente del plano de control que expone la API (Application Programming Interface). Es, esencialmente, una API REST (Representational State Transfer) masiva que funciona como el front end para el plano de control y permite que el usuario defina y controle todas las funciones de la administración de Kubernetes. La forma más fácil de usar la API es usar la interfaz de línea de comando kubectl (o oc para OpenShift). 

Los atacantes que tengan éxito en acceder a la API pueden llevar a cabo cualquier objetivo de su elección. Pueden, por ejemplo, instalar containers maliciosos para extraer información de bases de datos o usar recursos para campañas de cryptomining. 

Asegurarse de que esta API sólo pueda ser alcanzada por máquinas en un cluster y máquinas que necesiten administrar el cluster ayudará a mantener a raya a los cibercriminales. 

Para lograrlo, los administradores de la nube deben tener en cuenta que, por defecto, kube-api-server escucha en dos puertos: 

 

• Puerto 8080 solamente en localhost

• Cualquier solicitud a la API a través de este puerto evade los módulos de autenticación y autorización.

• Este puerto puede escuchar a otros hosts cuando se usa el flag –insecure-bind-address

• El puerto por defecto puede cambiarse con el flag –insecure-port.

• Puerto 6443 en una dirección IP pública

• Esta es la primera interfaz de red no localhost por defecto, también llamada un “puerto seguro.”

• Las solicitudes se envían correctamente a través de autenticación y autorización

• El puerto por defecto puede cambiarse con el flag–secure-port. 

 

Enfocarse en fortalecer la seguridad de los puertos 8080 y 6443, y estar consciente de qué es lo que no se debe de hacer con ellos ayudará a prevenir intrusiones. 

 

Sugerencias para proteger clusters contra ataques externos 

 

• Use una regla de firewall que asegure que solamente las máquinas que necesiten acceso a la API lo tengan.

• No use la opción –insecure-bind-address para abrir el puerto de texto plano en un no–localhost

• Use IPSs (Intrusion Prevention Systems) con capacidades de desencripción SSL (Secure Sockets Layer), como la solución de Trend Micro™ TippingPoint™ Threat Protection System, para permitir el monitoreo de tráfico desde y hacia la API para detectar vulnerabilidades conocidas y de día-cero. 

 

Temas de configuración 

 

Kubernetes es un sistema complejo que ofrece una gran flexibilidad a través de sus opciones de configuración. Pero estas opciones deben comprenderse adecuadamente y definirse de forma segura para evitar que el cluster se vea comprometido por actores maliciosos. 

Incluso la configuración de la autenticación puede ser compleja en Kubernetes porque existen múltiples modalidades de autenticación disponibles (basada en roles, en atributos o en nodos). Para ayudar a gestionar esto, los administradores de la nube pueden usar el comando kubectl auth can-i para solicitar permisos específicos. Los usuarios y las cuentas de servicio de Kubernetes deberían estar bloqueadas para que únicamente se usen los permisos necesarios. 

La razón por la que hacemos énfasis en este aspecto de la configuración de Kubernetes es porque hemos observado un número desafortunado de casos de temas de configuración que continúan ocurriendo en el panorama. Por ejemplo, un escaneo Shodan rápido, como se muestra en la figura 2, puede indicar que hay casi 3,000 hosts (repartidos alrededor del mundo) donde etcd, un valor clave usado por Kubernetes y por lo tanto uno que no debería estar expuesto, es públicamente accesible. 

 

[image url=”http://blog.la.trendmicro.com/wp-content/uploads/2020/06/KubernetesGuidanceFig-2.png” raw=”true” alignment=”center” margin_left=”0″ margin_right=”0″ margin_top=”0″ margin_bottom=”0″]

Figura 2. Un escaneo Shodan de servicios etcd expuestos (al 23 de marzo de 2020) 

 

Otra cosa que los administradores de la nube deben tener en mente es que no hay una política de red específica para un namespace específico, la política por defecto es permitir todo el tráfico desde y hacia todos los pods en ese namespace. Cada pod puede hablar con todos los demás pods, por lo que si un atacante puede acceder a uno que esté de vista al público (con una web app, por ejemplo), entonces el atacante puede usarlo para conectar con otros pods. Esto hace que el movimiento lateral sea más sencillo en caso de una brecha. 

La mejor práctica es negar el acceso por defecto y permitir únicamente el tráfico explícito. Mínimo, debería existir una política que niegue el tráfico de ingreso. Los administradores de la nube pueden crear esta política al implementar el código específico ofrecido en la documentación oficial de Kubernetes. 

 

Sugerencias para la protección de clusters contra temas de configuración 

 

• Realice una auditoría profunda de todos sus usuarios y cuentas de servicio de Kubernetes para asegurar que se tiene acceso solamente a las operaciones necesarias. Una revisión regular debería realizarse de ahí en adelante para asegurar el cumplimiento.

• Considere usar una distribución de Kubernetes que, aunque de alguna forma puede limitar las opciones, ofrece configuraciones seguras out-of-the-box, como OpenShift de Red Hat.

• Revise la guía con instrucciones específicas del proveedor de nube. (Dependiendo de dónde se despliega un cluster, la mayoría de los proveedores de la nube tendrán esta guía.) Tambien revise el CIS Kubernetes Benchmark del Center for Internet Security.

• Asegúrese de que todos los servicios utilizados por Kubernetes tienen firewalls apropiados y no están expuestos públicamente.

• Ponga atención a las políticas de red y niegue el tráfico de ingreso por defecto. 

 

Aplicaciones vulnerables 

 

Como con los servidores y sistemas operativos regulares, sin importar cuánto esfuerzo se le ponga a la protección de un cluster de Kubernetes, este solamente está tan seguro como el servicio más expuesto y débil. Los containers y orquestadores de containers facilitan no solamente el despliegue de una gran variedad de aplicaciones en un ambiente heterogéneo, sino también el uso combinado de las aplicaciones en un número significativo de permutaciones. Pero no resuelven todo. De hecho, la naturaleza de los containers puede hacer que asegurarse de que las actualizaciones se aplican en todos los lugares donde deben estar sea más difícil porque cada aplicación tiene su propia copia de cada biblioteca. 

Como se ilustra en la Figura 3, la misma biblioteca puede instalarse en múltiples imágenes, desde diferentes imágenes base. Y todas estas necesitan actualizarse y tener parches de seguridad aplicados. Integrar una solución como Trend Micro Deep Security™ Smart Check  en el proceso de DevOps puede ayudar en este sentido. 

 

[image url=”http://blog.la.trendmicro.com/wp-content/uploads/2020/06/KubernetesGuidanceFig-3-01.jpg” raw=”true” alignment=”center” margin_left=”0″ margin_right=”0″ margin_top=”0″ margin_bottom=”0″]

Figura 3. Las bibliotecas se despliegan a lo largo de múltiples imágenes, muchas de las cuales tienen bases diferentes y puede que se necesiten actualizar por varias partes. 

 

Sugerencias para proteger clusters contra aplicaciones vulnerables 

 

• Mínimo, asegúrese de que todas las imágenes del container están actualizadas y se están descargando desde fuentes confiables.

• Use tecnologías de escaneo automático específico a containers como las que se encuentran en Trend Micro™ Deep Security™ Smart Check – Container Image Security para escanear imágenes para aplicaciones como parte del proceso de integración continua y entrega continua (CI/CD). 

 

Protegiendo clusters con seguridad específica de la nube

Los containers ofrecen un paso hacia adelante tanto en DevOps y la seguridad (DevSecOps) a través de un mejor aislamiento de procesos. Los orquestadores de containers como Kubernetes ofrece un nivel importante de abstracción hacia arriba para hacerlos más útiles en un entorno escalable. Dicho esto, desplegarlos puede ser complicado, y tomar los pasos descritos arriba le ayudarán a asegurar que sus ambientes en la nube se encuentran protegidos. Las soluciones de seguridad específicas para la nube como Trend Micro™ Hybrid Cloud Security y Trend Micro Cloud One™ pueden optimizar la protección en estas instancias. 

Hybrid Cloud Security ofrece protección contra amenazas para proteger workloads y containers físicos, virtuales y en la nube en runtime. También escanea imágenes de container durante las fases de desarrollo.  

Cloud One, una plataforma de servicios de seguridad para desarrolladores en la nube, ofrece protección automatizada para aplicaciones y el pipeline CI/CD. También ayuda a identificar y resolver problemas de seguridad de forma más temprana, y a mejorar el tiempo de entrega para los equipos de DevOps. Incluye: 

 

• Workload Security: protección en runtime para workloads

• Container Security: escaneo automatizado de imágenes y registros de container

• File Storage Security: seguridad para servicios de almacenamiento de archivos y objetos en la nube

• Network Security: seguridad IPS para la capa de la red en la nube

• Application Security: seguridad para funciones serverless, APIs y aplicaciones 

• Conformity: protección en tiempo real para la infraestructura en la nube – proteja, optimice, cumpla