Gestión de las amenazas de seguridad en tiempo de ejecución en Kubernetes
La mayoría de los administradores sabe qué es la seguridad en tiempo de ejecución y por qué es importante. Sin embargo, a menudo la descuidan o no invierten lo suficiente en ella como parte de su estrategia de seguridad de Kubernetes.
Es fácil entender por qué: Kubernetes es un sistema tan complejo y ofrece tantos tipos diferentes de herramientas nativas para ayudar a acceder a los privilegios y aislar workloads que no es raro que los equipos se concentren en la seguridad del propio clúster y se olviden de la seguridad del tiempo de ejecución de Kubernetes.
Para ayudar a solucionar esto, en este artículo explicamos por qué la seguridad en tiempo de ejecución en Kubernetes es tan importante y de qué herramientas dispone para asegurar Kubernetes contra las amenazas en tiempo de ejecución.
¿Qué es la seguridad en tiempo de ejecución en Kubernetes?
La seguridad en tiempo de ejecución de Kubernetes es la protección de los containers (o pods) contra las amenazas activas una vez que los containers se están ejecutando.
La seguridad en tiempo de ejecución ayuda a proteger las workloads contra una serie de amenazas que pueden aparecer tras haber desplegado los containers, como por ejemplo:
- La activación de malware oculto en una imagen de container.
- Ataques de escalada de privilegios en los que un container aprovecha los fallos de seguridad en el tiempo de ejecución del container, Kubernetes o el OS anfitrión para acceder a recursos a los que no debería poder acceder (como volúmenes de almacenamiento o binarios externos).
- El despliegue de containers no autorizados por parte de un atacante que aprovecha una brecha en una política de control de acceso o un fallo de seguridad en Kubernetes.
- El acceso no autorizado a secretos u otra información sensible que un container en ejecución no debería poder leer, pero al que consigue acceder debido a una configuración del control de acceso incorrecta o a una vulnerabilidad de seguridad que permite la escalada de privilegios.
En un mundo ideal, estas amenazas en tiempo de ejecución no sucederían nunca, porque usted protegería sus pipelines de aplicaciones y clústeres de tal manera que las amenazas no consiguieran abrirse paso a un entorno activo. También utilizaría estrictos controles de acceso para garantizar que cada workload estuviera debidamente aislada, evitando así que un container comprometido causara algún daño al clúster.
Pero en el mundo real es imposible garantizar que los atacantes no introduzcan malware en una imagen de container comprometiendo así, por ejemplo, su repositorio de código fuente o sus herramientas de compilación, o que sus políticas RBAC y contextos de seguridad de Kubernetes garanticen un perfecto aislamiento entre workloads.
Por eso es tan importante la seguridad en tiempo de ejecución, ya que constituye la última capa de defensa contra las amenazas que pueden introducirse en un entorno de Kubernetes. Aunque puede, y debe, tomar todas las medidas razonables para mitigar los riesgos de seguridad dentro de la arquitectura de pipeline y de clúster, también necesita la seguridad en tiempo de ejecución para alertarle y controlar las amenazas que se cuelan en sus otras defensas.
Herramientas de seguridad en tiempo de ejecución de Kubernetes
Kubernetes ofrece relativamente poco en cuanto a herramientas de seguridad en tiempo de ejecución. El único recurso real que proporciona es la auditoría, que le permite generar registros que rastrean las solicitudes de recursos a la API de Kubernetes.
Sin embargo, aunque Kubernetes puede registrar esta información, no hace nada por sí mismo para analizar los registros de auditoría o alertarle de actividades sospechosas.
Por lo tanto, en lugar de recurrir al propio Kubernetes para proteger su entorno contra las amenazas en tiempo de ejecución, tendrá que apoyarse en herramientas externas de seguridad en tiempo de ejecución. En el caso de Kubernetes, estas herramientas se dividen en dos categorías principales: herramientas de aplicación y herramientas de auditoría.
Herramientas de aplicación de la seguridad en tiempo de ejecución
Las herramientas de aplicación permiten definir políticas que restringen los derechos de acceso y los permisos de los recursos dentro de un entorno de tiempo de ejecución. Aunque las herramientas no pueden evitar que se produzca una amenaza, sí pueden minimizar su impacto asegurando que, por ejemplo, el malware que aparece dentro de un container no pueda acceder a recursos externos al mismo.
Las principales herramientas de aplicación para Kubernetes son:
- Seccomp: Seccomp es una herramienta en el núcleo de Linux que puede utilizar para hacer que los procesos se ejecuten en un estado seguro. Cuando se utiliza seccomp para que un proceso pase a un estado seguro, el núcleo impedirá que el proceso realice cualquier llamada al sistema que no sea exit, sigreturn, read y write en archivos ya abiertos.
- SELinux: SELinux es un módulo del núcleo que permite definir un gran número de controles de acceso que el núcleo aplica. Puede utilizar SELinux para establecer reglas granulares sobre los recursos a los que puede acceder un container y los tipos de acciones que puede realizar.
- AppArmor: AppArmor es también un módulo del núcleo que permite definir un amplio conjunto de reglas de control de acceso. Es muy similar a SELinux en muchos aspectos. El debate sobre si utilizar SELinux o AppArmor es el mismo que entre vi y emacs: algunos prefieren una herramienta u otra, pero se pueden conseguir los mismos resultados generales con cualquiera de las dos soluciones.
En cierta medida, se puede pensar que las políticas RBAC de Kubernetes y los contextos de seguridad también proporcionan un cierto nivel de control de la aplicación, ya que se pueden utilizar para hacer cosas como evitar que un container se ejecute en modo privilegiado o para denegar el acceso a los recursos a nivel del núcleo.
Sin embargo, la diferencia entre las políticas RBAC y los contextos de seguridad, por un lado, y herramientas como SELinux y AppArmor, por otro, es que estas últimas aplican controles de acceso a nivel del núcleo. Esto significa que, incluso si Kubernetes se ve comprometido de alguna manera o tiene una vulnerabilidad de seguridad, las herramientas de aplicación a nivel del núcleo pueden mitigar el impacto de una brecha de seguridad al impedir que los containers comprometidos accedan a recursos externos.
SELinux, AppArmor y seccomp también son útiles porque pueden utilizarse para controlar el acceso de cualquier tipo de workload de Linux. No son exclusivos de Kubernetes. Si está gestionando un entorno que incluye una mezcla de containers y VMs, puede que le resulten útiles los marcos de control de acceso a nivel de núcleo, ya que le permiten usar las mismas herramientas para gestionar todas sus workloads.
Herramientas de auditoría para la seguridad en tiempo de ejecución
Las herramientas de auditoría en Kubernetes le ayudan a detectar y reaccionar ante las amenazas basándose en los datos recopilados de su clúster.
También en este caso Kubernetes proporciona las herramientas para generar registros de auditoría, pero no analiza los registros por usted. Para ello, deberá utilizar una herramienta como Falco, un motor de detección de amenazas de código abierto. Falco le permite definir reglas que activen alertas si detecta la presencia de ciertas condiciones basadas en datos como los registros de auditoría de Kubernetes.
Por ejemplo, considere esta regla de Falco:
- rule: Example rule (nginx). This is the human name for the rule.
desc: Detect any listening socket outside our expected one.
condition: evt.type in (accept,listen) and (container.
image!=myregistry/nginx or proc.name!=nginx or k8s.ns.name!=”load-
balancer”)
output: This is where I write the alert message and I provide some
extra information (command=%proc.cmdline connection=%fd.name).
priority: WARNING
En esta regla, cualquier socket de escucha que no cumpla con los siguientes criterios activará una alerta:
- La imagen es myregistry/nginx.
- El proceso de escucha es nginx.
- El namespace es load-balancer.
Una regla como esta le permite detectar los containers que se ejecutan en su entorno y que pueden estar intentando recopilar datos o acceder a recursos no autorizados. También puede este tipo de regla para detectar containers no autorizados.
Falco se ha convertido en la herramienta de auditoría de facto para Kubernetes y plataformas similares por varias razones. Además de ser de código abierto, Falco ofrece la posibilidad de trabajar con cualquier tipo de entorno nativo de la nube, no solo con Kubernetes.
Asimismo, el repositorio Cloud Native Security Hub, que ofrece docenas de reglas de Falco preconfiguradas y adaptadas a diferentes tipos de workloads, facilita la configuración de Falco de forma rápida sin tener que escribir un montón de reglas de auditoría a mano.
Mejores prácticas para la seguridad en tiempo de ejecución de Kubernetes
Aunque el despliegue de herramientas de aplicación y auditoría es uno de los pasos necesarios para hacer frente a las amenazas de seguridad en tiempo de ejecución de Kubernetes, es conveniente que vaya más allá de la simple configuración de estas herramientas. También debe asegurarse de lo siguiente:
- Realice un escaneo continuo de imágenes: Si bien el escaneo de imágenes no es una operación de seguridad en tiempo de ejecución en sí misma (entra en el ámbito de la seguridad de pipelines), sí es importante para evitar que el malware llegue a un entorno de tiempo de ejecución.
- Escanee los archivos de políticas de Kubernetes: También puede prevenir problemas de seguridad en tiempo de ejecución analizando los archivos RBAC de Kubernetes, los despliegues y otros recursos para detectar errores de configuración que pudieran desencadenar o agravar una brecha en tiempo de ejecución.
- Escanee los archivos de políticas externas: De igual modo, debería analizar los archivos de políticas o perfiles que cree para SELinux, AppArmor u otros marcos. Los descuidos en estos archivos podrían debilitar sus defensas en tiempo de ejecución.
- No se olvide de dev/test: Al implementar las defensas de seguridad en tiempo de ejecución, es probable que se centre primero en su entorno de producción. Al fin y al cabo, es donde más impacto suelen tener las amenazas. Pero no se olvide de proteger también el entorno de desarrollo y prueba. Detectar las amenazas en tiempo de ejecución en el entorno de desarrollo/prueba es una buena manera de evitar que lleguen a producción. Además, un problema de seguridad en tiempo de ejecución también podría tener consecuencias importantes en un entorno de desarrollo/prueba si, por ejemplo, un atacante consigue acceder a datos secretos desde los recursos de desarrollo y prueba.
- Elabore un plan para subsanar los incidentes: No espere a que se produzca una brecha para empezar a planificar su respuesta. Elabore manuales de actuación que ayuden a su equipo a gestionar diferentes tipos de eventos de seguridad en tiempo de ejecución. Por ejemplo, ¿qué hacer en caso de un ataque de escalada de privilegios? ¿Y si un nodo está comprometido pero otros nodos no lo están? Pensar en estas cuestiones de antemano le ayudará a responder más rápidamente a las amenazas activas.
La seguridad en tiempo de ejecución es lo único que se interpone entre su clúster y las amenazas que han conseguido eludir las demás defensas colocadas en su pipeline de desarrollo de aplicaciones y su arquitectura Kubernetes. Pero si audita continuamente sus entornos de tiempo de ejecución y utiliza herramientas de aplicación para separar los recursos de tiempo de ejecución entre sí, conseguirá minimizar el posible impacto de las amenazas en tiempo de ejecución.