En el panorama cambiante de la orquestación de contenedores, Kubernetes se ha convertido en el estándar de facto debido a su flexibilidad, escalabilidad y sólido soporte comunitario. Sin embargo, como ocurre con cualquier sistema complejo, proteger un entorno de Kubernetes presenta desafíos únicos. Los contenedores, por su propia naturaleza, son transitorios y multifacéticos, lo que hace que los métodos de seguridad tradicionales sean menos efectivos. Aquí es donde Falco, un proyecto de código abierto de Cloud Native Computing Foundation (CNCF), se vuelve invaluable.

Falco está diseñado para proporcionar monitoreo de seguridad y detección de anomalías para Kubernetes, lo que permite a los equipos detectar actividades maliciosas y vulnerabilidades en tiempo real. Opera interceptando y analizando llamadas al sistema para identificar comportamientos inesperados dentro de las aplicaciones que se ejecutan en contenedores. Como herramienta nativa de la nube, Falco se integra perfectamente en los entornos de Kubernetes, ofreciendo conocimientos profundos y medidas de seguridad proactivas sin la sobrecarga de las herramientas de seguridad tradicionales.

Cómo hackear pods de Kubernetes y ejecutar código malicioso de forma remota

A medida que los equipos se embarcan en proteger sus clústeres de Kubernetes, aquí hay varias reglas de Falco que se recomiendan para fortalecer sus implementaciones de manera efectiva:

1. PÓNGASE EN CONTACTO CON EL SERVIDOR API K8S DESDE EL CONTENEDOR

La regla de Falco “Contactar con el servidor API K8S desde el contenedor” está diseñada para detectar intentos de comunicarse con el servidor API Kubernetes (K8s) desde un contenedor, particularmente por parte de usuarios que no están perfilados ni se espera que lo hagan. Esta regla es crucial porque la API de Kubernetes desempeña un papel fundamental en la gestión del ciclo de vida del clúster y el acceso no autorizado podría generar importantes problemas de seguridad.

DETALLES DE LA REGLA:

• Propósito : auditar y marcar cualquier intento inesperado o no autorizado de acceder al servidor API de Kubernetes desde un contenedor. Esto podría indicar un intento de explotar el plano de control del clúster o manipular su configuración.
• Estrategia de detección : la regla monitorea las conexiones de red realizadas a los puertos típicos del servidor API y verifica si estas conexiones son realizadas por entidades (usuarios o procesos) que no están explícitamente permitidas o perfiladas en la política de seguridad.
• Aplicabilidad de la carga de trabajo : esta regla se aplica en entornos donde los contenedores normalmente no deberían necesitar interactuar directamente con el servidor API de Kubernetes, o donde dichas interacciones deben limitarse a ciertos perfiles.

MAPEO DEL MARCO MITRE ATT&CK:

• Táctica : acceso a credenciales, descubrimiento
• Técnica : T1552.004 (Credenciales no seguras: Kubernetes)

ESCENARIO DE EJEMPLO:

Supongamos que un contenedor inicia inesperadamente una conexión con el servidor API de Kubernetes utilizando kubectlun cliente similar. La regla podría marcar esta actividad si el contenedor y su usuario no se encuentran entre los que se espera o están perfilados para realizar tales acciones. Monitorear estas conexiones ayuda a la detección temprana de posibles infracciones o uso indebido de la infraestructura de Kubernetes.

Esta regla, al monitorear dichas interacciones críticas, ayuda a mantener la seguridad y la integridad de los entornos de Kubernetes, garantizando que solo se produzcan comunicaciones autorizadas y previstas entre los contenedores y el servidor API de Kubernetes.

2. PUERTO NO ESTÁNDAR DE CONEXIÓN SSH NO PERMITIDO

La regla de seguridad de Falco “Puerto no estándar de conexión SSH no permitida” está diseñada para detectar cualquier nueva conexión SSH saliente desde un host o contenedor que utilice puertos no estándar. Esto es importante porque SSH normalmente opera en el puerto 22 y las conexiones en otros puertos pueden indicar un intento de evadir la detección.

DETALLES DE LA REGLA:

• Propósito : monitorear y marcar conexiones SSH que se realizan desde puertos no estándar, lo que podría ser indicativo de un compromiso de seguridad, como un shell inverso o una vulnerabilidad de inyección de comandos que se está explotando.
• Estrategia de detección : la regla busca nuevas conexiones SSH salientes que no utilicen el puerto SSH estándar. Está particularmente enfocado en detectar escenarios de shell inverso donde la máquina víctima se conecta nuevamente a la máquina de un atacante, con comando y control facilitados a través del protocolo SSH.
• Configuración : la regla sugiere que es posible que los usuarios necesiten expandir la lista de puertos monitoreados según la configuración de su entorno específico y los posibles escenarios de amenazas. Esto puede incluir agregar más puertos o rangos no estándar que sean relevantes para la configuración de su red.

ESCENARIO DE EJEMPLO:

Una aplicación en un host podría verse comprometida al ejecutar un comando que inicia una conexión SSH a un servidor externo en un puerto no estándar, como 2222 o 8080. Esto podría ser parte de un ataque de inyección de comandos en el que el atacante ha adquirido la capacidad. para ejecutar comandos arbitrarios en el host.

Esta regla ayuda a detectar este tipo de actividades, que normalmente son señales de alerta para la filtración de datos, la ejecución remota de comandos o el establecimiento de un punto de apoyo dentro de la red a través de medios no convencionales. Al marcar estas actividades, los administradores pueden investigar y responder a posibles incidentes de seguridad de manera más efectiva.

3. LECTURA DE ARCHIVOS MONITOREADOS POR RECORRIDO DE DIRECTORIO

La regla de Falco “Lectura de archivos monitoreados por recorrido de directorio” tiene como objetivo detectar y alertar sobre ataques de cruce de directorio específicamente cuando implican la lectura de archivos de directorios críticos del sistema a los que generalmente se accede a través de rutas absolutas. Esta regla es fundamental para evitar que los atacantes aprovechen las vulnerabilidades para acceder a información confidencial fuera de los directorios de archivos previstos, como la raíz de la aplicación web.

DETALLES DE LA REGLA:

• Propósito : monitorear y alertar sobre intentos de leer archivos de directorios confidenciales, como /etcmediante ataques de cruce de directorios. Estos ataques aprovechan vulnerabilidades que permiten a los atacantes acceder a archivos y directorios que se encuentran fuera del directorio raíz del servidor web.
• Estrategia de detección : la regla se centra en detectar operaciones de lectura en archivos confidenciales a los que no se debe acceder en circunstancias operativas normales. Los patrones de acceso que se desvían de la norma (por ejemplo, acceder a archivos a través de rutas que navegan hacia arriba en el árbol de directorios mediante ../) se marcan.
• Aplicabilidad de la carga de trabajo : esta regla es particularmente importante para entornos que ejecutan aplicaciones web donde se podrían aprovechar las vulnerabilidades de cruce de directorios.

ESCENARIO DE EJEMPLO:

Un atacante podría aprovechar una vulnerabilidad en una aplicación web para leer el /etc/passwdarchivo enviando una solicitud como GET /api/files?path=../../../../etc/passwd. Esta acción intenta salir de la estructura de directorios prevista para acceder a información confidencial. La regla señalaría tales intentos y proporcionaría una alerta a los administradores del sistema.

Esta regla ayuda a mantener la integridad y seguridad del sistema de archivos de la aplicación al garantizar que solo se produzcan accesos legítimos y previstos a los archivos, evitando la divulgación de información no autorizada a través de vulnerabilidades web comunes.

4. EJECUCIÓN REMOTA DE CÓDIGO NETCAT EN CONTENEDOR

La regla de seguridad de Falco “Ejecución remota de código en contenedor Netcat” está diseñada para detectar casos en los que la herramienta Netcat se utiliza dentro de un entorno de contenedor de una manera que podría facilitar la ejecución remota de código. Esto es particularmente preocupante porque Netcat es una herramienta de red versátil que puede usarse maliciosamente para establecer puertas traseras y ejecutar comandos de forma remota.

DETALLES DE LA REGLA:

• Propósito : Monitorear y alertar sobre el uso del programa Netcat (nc) dentro de contenedores, lo que podría indicar un intento de uso indebido para la ejecución remota de comandos no autorizados.
• Estrategia de detección : la regla marca la ejecución de Netcat dentro de un contenedor, lo que suele ser inesperado en un entorno controlado. Esta detección se centra en usos de Netcat que podrían facilitar el establecimiento de un shell remoto u otras vías de ejecución de comandos desde fuera del contenedor.
• Aplicabilidad de la carga de trabajo : esta regla es importante en entornos donde se utilizan contenedores para alojar aplicaciones y donde debe haber controles estrictos sobre qué utilidades ejecutables están permitidas.

ESCENARIO DE EJEMPLO:

Un atacante podría aprovechar una vulnerabilidad dentro de una aplicación que se ejecuta dentro de un contenedor para descargar y ejecutar Netcat. Luego, podrían usarlo para abrir un puerto que escuche las conexiones entrantes, permitiendo al atacante ejecutar comandos arbitrarios de forma remota. Esta configuración podría usarse para la filtración de datos, la implementación de malware adicional o una mayor explotación de la red.

Al detectar el uso de Netcat en tales escenarios, los administradores pueden responder rápidamente a posibles violaciones de seguridad, mitigando los riesgos asociados con el acceso remoto no autorizado. Esta regla ayuda a garantizar que los contenedores, que a menudo forman parte de una arquitectura de microservicios más amplia, no se conviertan en puntos de entrada para los atacantes.

5. CARCASA TERMINAL EN CONTENEDOR

La regla de seguridad de Falco “Terminal Shell en contenedor” está diseñada para detectar casos en los que se utiliza un shell como punto de entrada o ejecución en un contenedor, particularmente con una terminal adjunta. Este monitoreo es crucial porque el acceso inesperado a la terminal dentro de un contenedor puede ser una señal de actividad maliciosa, como que un atacante obtenga acceso para ejecutar comandos o scripts.

DETALLES DE LA REGLA:

• Propósito : monitorear el uso de shells interactivos dentro de los contenedores, lo que podría indicar una intrusión o un uso indebido. Las carcasas de terminales normalmente no se utilizan en contenedores de producción a menos que sea para fines administrativos o de depuración, por lo que su uso puede ser una señal de alerta.
• Estrategia de detección : la regla marca instancias en las que se inicia un proceso de shell con interacción de terminal dentro de un contenedor. Puede ayudar a identificar el uso indebido, como el que un atacante utiliza kubectl execpara ejecutar comandos dentro de un contenedor o mediante otros medios como SSH.
• Aplicabilidad de la carga de trabajo : esta regla es particularmente importante en entornos donde se espera que los contenedores ejecuten tareas predefinidas sin sesiones interactivas.

ESCENARIO DE EJEMPLO:

Un atacante o un usuario no autorizado obtiene acceso a un clúster de Kubernetes y lo utiliza kubectl execpara iniciar un shell bash en un contenedor en ejecución. Esta acción estaría marcada por la regla, especialmente si el shell se inicia con un terminal conectado, lo que es indicativo de uso interactivo.

Esta regla ayuda a garantizar que los contenedores, que normalmente deberían ejecutarse sin sesiones interactivas, no se utilicen indebidamente para actividades potencialmente dañinas. Es una herramienta de auditoría básica que se puede adaptar para incluir una lista más amplia de procesos o condiciones reconocidos bajo los cuales los shells pueden usarse legítimamente, reduciendo así los falsos positivos y manteniendo la seguridad.

6.PACKET SOCKET CREADO EN CONTENEDOR

La regla de seguridad de Falco “Packet Socket Creado en Contenedor” está diseñada para detectar la creación de sockets de paquetes en el nivel del controlador de dispositivo (OSI Layer 2) dentro de un contenedor. Este tipo de socket se puede utilizar para tareas como la suplantación de ARP y también está vinculado a vulnerabilidades conocidas que podrían permitir la escalada de privilegios, como CVE-2020-14386.

DETALLES DE LA REGLA:

• Propósito : La intención principal de esta regla es monitorear y alertar sobre la creación de sockets de paquetes dentro de contenedores, una actividad potencialmente sospechosa que podría ser indicativa de actividades nefastas como rastreo de redes o ataques de suplantación de ARP. Estos ataques pueden interrumpir o interceptar el tráfico de la red, y la capacidad de crear sockets de paquetes podría usarse para explotar ciertas vulnerabilidades que conducen a privilegios elevados dentro del sistema host.
• Estrategia de detección : esta regla rastrea la creación de instancias de sockets de paquetes, que interactúan directamente con la capa 2 de OSI, lo que les permite enviar y recibir paquetes en el nivel del controlador de interfaz de red. Por lo general, esto va más allá de la necesidad de las operaciones de contenedores estándar y puede sugerir una infracción o un intento de explotación.
• Aplicabilidad de la carga de trabajo : es crucial para entornos donde los contenedores forman parte de una red segura y controlada y no deberían requerir acceso a la red de bajo nivel. La creación de dichos sockets en una aplicación web estándar o en un contenedor de procesamiento de datos suele ser fuera de lo común y merece una mayor investigación.

ESCENARIO DE EJEMPLO:

Considere un contenedor que se ha visto comprometido a través de una vulnerabilidad de una aplicación web que permite a un atacante ejecutar comandos arbitrarios. El atacante podría intentar crear un socket de paquetes para realizar una suplantación de ARP, posicionando el contenedor comprometido para interceptar o manipular el tráfico dentro de su subred conectada para robar datos o realizar más ataques.

Esta regla ayuda a la detección temprana de dichos vectores de ataque, iniciando alertas que permiten a los administradores del sistema tomar medidas rápidas, como aislar el contenedor afectado, realizar un análisis forense para comprender el alcance de la infracción y reforzar las medidas de seguridad de la red para evitar incidentes similares.

Al implementar esta regla, las organizaciones pueden mejorar sus capacidades de monitoreo contra ataques sofisticados a nivel de red que hacen un mal uso de los entornos en contenedores, garantizando que su infraestructura permanezca segura contra amenazas tanto internas como externas. Esta medida proactiva es un componente crítico de una estrategia de seguridad integral, especialmente en plataformas complejas de orquestación de contenedores multiinquilino como Kubernetes.

7.DEBUGFS LANZADO EN UN CONTENEDOR PRIVILEGIADO

La regla de seguridad de Falco “Debugfs lanzados en un contenedor privilegiado” está diseñada para detectar la activación del debugfsdepurador del sistema de archivos dentro de un contenedor que tiene acceso privilegiado. Esta situación puede provocar potencialmente violaciones de seguridad, incluido el escape de contenedores, porque debugfsproporciona un acceso profundo a las estructuras internas del kernel de Linux.

DETALLES DE LA REGLA:

• Propósito : monitorear el uso de debugfscontenedores privilegiados, lo que podría exponer datos confidenciales del kernel o permitir modificaciones que conduzcan a vulnerabilidades de escalada de privilegios. La regla apunta a una actividad específica y peligrosa que generalmente debería restringirse dentro de los entornos de producción.
• Estrategia de detección : esta regla marca cualquier instancia que debugfsesté montada o utilizada dentro de un contenedor que opere con privilegios elevados. Dada la naturaleza poderosa debugfsy los elevados privilegios de los contenedores, esta combinación puede ser particularmente arriesgada.
• Aplicabilidad de la carga de trabajo : esta regla es crucial en entornos donde los contenedores tienen acceso privilegiado y es necesario controlar estrictamente las herramientas y comandos que pueden interactuar con el núcleo del sistema.

ESCENARIO DE EJEMPLO:

Considere un escenario en el que un operador habilita por error o maliciosamente debugfsdentro de un contenedor privilegiado. Un atacante podría aprovechar esta configuración para manipular los datos del kernel o escalar sus privilegios dentro del sistema host. Por ejemplo, podrían usarlo debugfspara modificar los parámetros de tiempo de ejecución o extraer información confidencial directamente de la memoria del kernel.

La supervisión del uso de debugfscontenedores privilegiados es un control de seguridad fundamental para evitar posibles vulnerabilidades. Al detectar el uso no autorizado o inesperado de esta poderosa herramienta, los administradores de sistemas pueden tomar medidas inmediatas para investigar y remediar la situación, manteniendo así la integridad y seguridad de sus entornos en contenedores.

8. EJECUCIÓN DESDE /DEV/SHM

La regla de seguridad de Falco “Ejecución desde /dev/shm” está diseñada para detectar ejecuciones que ocurren dentro del /dev/shmdirectorio. Este directorio se utiliza normalmente para la memoria compartida y los actores de amenazas pueden abusar de él para ejecutar archivos o scripts maliciosos almacenados en la memoria, lo que puede ser un método para evadir los mecanismos tradicionales de detección basados ​​en archivos.

DETALLES DE LA REGLA:

• Propósito : Monitorear y alertar sobre cualquier actividad ejecutable dentro del /dev/shmdirectorio. Este directorio permite el almacenamiento temporal con permisos de lectura, escritura y ejecución, lo que lo convierte en un objetivo potencial para que los atacantes lo exploten ejecutando archivos ejecutables directamente desde este espacio de memoria compartida.
• Estrategia de detección : la regla identifica cualquier ejecución de proceso que comience desde dentro del /dev/shmdirectorio. Este directorio también lo utilizan a menudo procesos legítimos, por lo que es posible que sea necesario ajustar la regla para minimizar los falsos positivos en entornos donde se espera dicho uso.
• Aplicabilidad de la carga de trabajo : esta regla es crucial para entornos donde es necesario un monitoreo estricto de las acciones ejecutables, particularmente en sistemas con requisitos de alta seguridad o donde la integridad del entorno de ejecución es crítica.

ESCENARIO DE EJEMPLO:

Un atacante obtiene acceso a un sistema y coloca un ejecutable malicioso en el /dev/shmdirectorio. Luego ejecutan este archivo, que podría ser un script o un binario, para realizar actividades maliciosas como establecer una puerta trasera, extraer datos o escalar privilegios. Dado que los archivos /dev/shmse pueden ejecutar en la memoria y no pueden dejar rastros en el disco, este método se usa comúnmente para evadir.

Al detectar ejecuciones de /dev/shm, los administradores pueden responder rápidamente a posibles violaciones de seguridad que utilizan esta técnica, mitigando así los riesgos asociados con el malware residente en la memoria y otras metodologías de ataque sin archivos. Este monitoreo es una medida proactiva para mejorar la postura de seguridad tanto de los entornos en contenedores como de los que no lo son.

9. REDIRIGIR STDOUT/STDIN A LA CONEXIÓN DE RED EN EL CONTENEDOR

La regla de seguridad de Falco “Redirigir STDOUT/STDIN a una conexión de red en un contenedor” está diseñada para detectar casos en los que la salida estándar (STDOUT) o la entrada estándar (STDIN) de un proceso se redirige a una conexión de red dentro de un contenedor. Este comportamiento se asocia comúnmente con shells inversos o ejecución remota de código, donde un atacante redirige la salida de un shell a una ubicación remota para controlar un contenedor o host comprometido.

DETALLES DE LA REGLA:

• Propósito : monitorear y alertar sobre la redirección de STDOUT o STDIN a conexiones de red dentro de contenedores, lo que puede indicar que un contenedor se está utilizando para establecer un shell inverso o ejecutar comandos remotos, un indicador de una infracción o actividad maliciosa.
• Estrategia de detección : esta regla detecta específicamente el uso de llamadas al sistema como dup(y sus variantes) que se emplean para redirigir STDOUT o STDIN a sockets de red. Esta actividad suele ser un componente de ataques que buscan controlar un proceso de forma remota.
• Aplicabilidad de la carga de trabajo : esta regla es particularmente importante en entornos donde no se espera que los contenedores inicien conexiones salientes o manipulen sus flujos de salida, lo que podría ser indicativo de actividades sospechosas o no autorizadas.

ESCENARIO DE EJEMPLO:

Un atacante explota una vulnerabilidad dentro de una aplicación web que se ejecuta dentro de un contenedor y obtiene acceso al shell. Luego ejecutan un comando que configura un shell inverso usando Bash, lo que implica redirigir la salida del shell a un socket de red que controlan. Esto permite al atacante ejecutar comandos arbitrarios en el contenedor infectado de forma remota.

Al monitorear y detectar dichas redirecciones, los administradores de sistemas pueden identificar y responder rápidamente a posibles incidentes de seguridad que involucren métodos sigilosos de acceso remoto. Esta regla ayuda a garantizar que los contenedores, que a menudo se administran y escalan dinámicamente, no se conviertan en conductos involuntarios para la filtración de datos o una mayor penetración en la red.

10. EJECUCIÓN SIN ARCHIVOS MEDIANTE MEMFD_CREATE

La regla de seguridad de Falco “Ejecución sin archivos a través de memfd_create” detecta cuando un binario se ejecuta directamente desde la memoria mediante la memfd_createllamada al sistema. Este método es una conocida técnica de evasión de defensa que permite a los atacantes ejecutar malware en una máquina sin almacenar ninguna carga útil en el disco, evitando así los típicos mecanismos de detección basados ​​en archivos.

DETALLES DE LA REGLA:

• Propósito : Monitorear y alertar sobre el uso de la memfd_createtécnica, que permite a los procesos crear archivos anónimos en la memoria que no están vinculados al sistema de archivos. Los atacantes pueden utilizar esta capacidad para ejecutar código malicioso sin dejar los rastros típicos en el sistema de archivos.
• Estrategia de detección : esta regla se activa cuando la memfd_createllamada al sistema se utiliza para ejecutar código, lo que puede ser un indicador de un intento de ocultar actividad maliciosa. Dado que memfd_createtambién se puede utilizar con fines legítimos, la regla puede incluir mecanismos para incluir en la lista blanca procesos buenos conocidos.
• Aplicabilidad de la carga de trabajo : es fundamental en entornos donde la integridad y la seguridad del entorno de ejecución son primordiales, particularmente en sistemas que manejan datos confidenciales o forman parte de una infraestructura crítica.

ESCENARIO DE EJEMPLO:

Un atacante aprovecha una vulnerabilidad en una aplicación web para obtener privilegios de ejecución en un host. En lugar de escribir un ejecutable malicioso en el disco, utilizan memfd_createpara cargar y ejecutar el binario directamente desde la memoria. Esta técnica ayuda al ataque a evadir la detección de las soluciones antivirus tradicionales que monitorean los sistemas de archivos en busca de cambios.

Al detectar ejecuciones a través de memfd_create, los administradores de sistemas pueden identificar y mitigar estos ataques sofisticados que de otro modo dejarían rastros mínimos. La implementación de dicha supervisión es esencial en entornos de alta seguridad para detectar técnicas avanzadas de malware que implican la ejecución sin archivos. Esto ayuda a mantener la integridad y seguridad de entornos en contenedores y no contenedores por igual.

11. ELIMINAR DATOS MASIVOS DEL DISCO

La regla de seguridad de Falco “Eliminar datos masivos del disco” está diseñada para detectar actividades en las que se eliminan grandes cantidades de datos de un disco, lo que podría indicar un intento de destruir pruebas o interrumpir la disponibilidad del sistema. Esta acción suele verse en escenarios en los que un atacante o una persona interna malintencionada intenta cubrir sus huellas o durante un ataque de ransomware en el que se borran datos.

DETALLES DE LA REGLA:

• Propósito : monitorear comandos o procesos que eliminan grandes cantidades de datos, lo que podría ser parte de una estrategia de destrucción de datos o un intento malicioso de afectar la integridad o disponibilidad de los datos en un sistema.
• Estrategia de detección : esta regla identifica procesos que inician eliminaciones masivas de datos, particularmente aquellos que podrían usarse en un contexto destructivo. La atención se centra en detectar comandos como rm -rf, shredu otras utilidades que sean capaces de borrar datos.
• Aplicabilidad de la carga de trabajo : es particularmente importante en entornos donde la integridad y la disponibilidad de los datos son críticas y donde la eliminación no autorizada de datos podría tener graves impactos en las operaciones comerciales o los requisitos de cumplimiento.

ESCENARIO DE EJEMPLO:

Un atacante obtiene acceso a un servidor de base de datos y ejecuta un comando para eliminar registros y otros archivos que podrían usarse para rastrear sus actividades. Alternativamente, en un ataque de ransomware, este tipo de comando podría usarse para eliminar copias de seguridad u otros datos importantes para aprovechar el cifrado de los sistemas para exigir un rescate.

Al detectar dichas actividades de eliminación masiva, los administradores del sistema pueden recibir alertas sobre posibles infracciones o acciones destructivas a tiempo para intervenir y posiblemente evitar daños mayores. Esta regla ayuda a mantener la seguridad y la integridad operativa de entornos donde la persistencia de los datos es un componente crítico.

Al implementar estas reglas de Falco, los equipos pueden mejorar significativamente la postura de seguridad de sus implementaciones de Kubernetes. Estas reglas proporcionan una capa fundamental de seguridad al monitorear y alertar sobre amenazas potenciales en tiempo real, lo que permite a las organizaciones responder rápidamente para mitigar los riesgos. A medida que Kubernetes continúe evolucionando, también lo harán las estrategias para protegerlo, lo que hace que el monitoreo y la adaptación continuos sean un componente crítico de cualquier estrategia de seguridad.