Runtime security con Falco: detectar lo que las Network Policies no pueden parar

Las Network Policies, Pod Security Admission y un RBAC bien ajustado tienen algo en común: son controles preventivos. Deciden qué se puede desplegar y con quién puede hablar cada pod. Pero ninguno te dice qué está pasando dentro de un contenedor que ya está en marcha.

Si alguien abre una shell en un pod de producción, lee el fichero de contraseñas del sistema o descarga un binario y lo ejecuta, ninguno de esos controles salta. Todo eso ocurre dentro de lo que ya estaba permitido. Para eso existe la seguridad en tiempo de ejecución, y la herramienta de referencia en el ecosistema es Falco, un proyecto graduado de la CNCF.

Cómo funciona, en corto. Falco corre como DaemonSet en cada nodo y observa las llamadas al sistema del kernel mediante eBPF. Las compara con un conjunto de reglas y, cuando una coincide, genera una alerta. Como también conoce el contexto de Kubernetes, la alerta no te dice solo “proceso bash en el PID 4312”. Te dice en qué pod, namespace y contenedor ha pasado.

rule: Shell en contenedor de producción
desc: Alguien ha abierto una shell interactiva en un pod de producción
condition: >
spawned_process and container
and shell_procs
and k8s.ns.name startswith “prod”
output: >
Shell abierta en producción (user=%user.name
pod=%k8s.pod.name ns=%k8s.ns.name)
priority: WARNING

Lo que suelo recomendar al desplegarlo:

1. Empieza con las reglas por defecto y en modo observación. El conjunto que trae Falco ya cubre lo más habitual: shells en contenedores, lectura de ficheros sensibles, escritura en directorios de binarios, cambios de privilegios… No escribas reglas propias hasta haber visto qué ruido genera tu cluster.
2. Dedica tiempo a reducir el ruido, no a ignorarlo. Las primeras semanas habrá falsos positivos: operadores que lanzan procesos legítimos, jobs de backup que leen ficheros “sensibles”… Ajústalos con excepciones concretas en las reglas, nunca desactivando la regla entera. Una herramienta que alerta de todo acaba con las alertas silenciadas, y entonces no sirve de nada.
3. Manda las alertas a donde alguien las vaya a ver. Una alerta que solo vive en los logs del pod de Falco no existe. Falcosidekick las reenvía a Slack, Teams, correo, tu SIEM o tu stack de logs. Decide antes quién recibe qué prioridad.
4. Ten un plan para cuando salte. Antes de activar alertas críticas, deja claro qué se hace cuando llega una: aislar el pod con una NetworkPolicy, capturar evidencias, escalar. Si no, la primera alerta real se convierte en una reunión improvisada.

Si usas OpenShift: Falco necesita acceso privilegiado al kernel de cada nodo, así que su ServiceAccount requiere la SCC privileged. Es una excepción justificada, pero documéntala y limítala a su namespace. Es justo el tipo de permiso que luego revisarás en una auditoría de RBAC.

Los controles preventivos reducen lo que puede salir mal. Los de runtime te dicen cuándo, a pesar de todo, ha salido mal. Necesitas los dos.

¿Tenéis algún tipo de detección en tiempo de ejecución en vuestros clusters, o todo se queda en controles de despliegue?

La seguridad en runtime, con Falco y reglas listas para adaptar, es uno de los apartados de mi manual “Seguridad y monitorización en Kubernetes” (950 páginas, en español). [Descarga la muestra gratuita]([URL de la muestra]) · Consigue el manual completo