{"id":3319,"date":"2026-10-14T15:03:44","date_gmt":"2026-10-14T13:03:44","guid":{"rendered":"https:\/\/djimn.com\/?p=3319"},"modified":"2026-10-14T15:26:45","modified_gmt":"2026-10-14T13:26:45","slug":"runtime_security_falco","status":"publish","type":"post","link":"https:\/\/djimn.com\/index.php\/2026\/10\/14\/runtime_security_falco\/","title":{"rendered":"Runtime security con Falco: detectar lo que las Network Policies no pueden parar"},"content":{"rendered":"<p dir=\"ltr\">Las Network Policies, Pod Security Admission y un RBAC bien ajustado tienen algo en com\u00fan: son controles <em>preventivos<\/em>. Deciden qu\u00e9 se puede desplegar y con qui\u00e9n puede hablar cada pod. Pero ninguno te dice qu\u00e9 est\u00e1 pasando dentro de un contenedor que ya est\u00e1 en marcha.<\/p>\n<p dir=\"ltr\">Si alguien abre una shell en un pod de producci\u00f3n, lee el fichero de contrase\u00f1as del sistema\u00a0o 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\u00f3n, y la herramienta de referencia en el ecosistema es Falco, un proyecto graduado de la CNCF.<\/p>\n<p dir=\"ltr\"><strong>C\u00f3mo funciona, en corto.<\/strong> 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\u00e9n conoce el contexto de Kubernetes, la alerta no te dice solo \u201cproceso bash en el PID 4312\u201d. Te dice en qu\u00e9 pod, namespace y contenedor ha pasado.<\/p>\n<p dir=\"ltr\">rule: Shell en contenedor de producci\u00f3n<br \/>\ndesc: Alguien ha abierto una shell interactiva en un pod de producci\u00f3n<br \/>\ncondition: &gt;<br \/>\nspawned_process and container<br \/>\nand shell_procs<br \/>\nand k8s.ns.name startswith &#8220;prod&#8221;<br \/>\noutput: &gt;<br \/>\nShell abierta en producci\u00f3n (user=%user.name<br \/>\npod=%k8s.pod.name ns=%k8s.ns.name)<br \/>\npriority: WARNING<\/p>\n<p dir=\"ltr\"><strong>Lo que suelo recomendar al desplegarlo:<\/strong><\/p>\n<ol dir=\"ltr\">\n<li><strong>Empieza con las reglas por defecto y en modo observaci\u00f3n.<\/strong> El conjunto que trae Falco ya cubre lo m\u00e1s habitual: shells en contenedores, lectura de ficheros sensibles, escritura en directorios de binarios, cambios de privilegios\u2026 No escribas reglas propias hasta haber visto qu\u00e9 ruido genera tu cluster.<\/li>\n<li><strong>Dedica tiempo a reducir el ruido, no a ignorarlo.<\/strong> Las primeras semanas habr\u00e1 falsos positivos: operadores que lanzan procesos leg\u00edtimos, jobs de backup que leen ficheros \u201csensibles\u201d\u2026 Aj\u00fastalos 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.<\/li>\n<li><strong>Manda las alertas a donde alguien las vaya a ver.<\/strong> Una alerta que solo vive en los logs del pod de Falco no existe. Falcosidekick las reenv\u00eda a Slack, Teams, correo, tu SIEM o tu stack de logs. Decide antes qui\u00e9n recibe qu\u00e9 prioridad.<\/li>\n<li><strong>Ten un plan para cuando salte.<\/strong> Antes de activar alertas cr\u00edticas, deja claro qu\u00e9 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\u00f3n improvisada.<\/li>\n<\/ol>\n<p dir=\"ltr\"><strong>Si usas OpenShift:<\/strong> Falco necesita acceso privilegiado al kernel de cada nodo, as\u00ed que su ServiceAccount requiere la SCC <code dir=\"ltr\">privileged<\/code>. Es una excepci\u00f3n justificada, pero docum\u00e9ntala y lim\u00edtala a su namespace. Es justo el tipo de permiso que luego revisar\u00e1s en una auditor\u00eda de RBAC.<\/p>\n<p dir=\"ltr\">Los controles preventivos reducen lo que puede salir mal. Los de runtime te dicen cu\u00e1ndo, a pesar de todo, ha salido mal. Necesitas los dos.<\/p>\n<p dir=\"ltr\">\u00bfTen\u00e9is alg\u00fan tipo de detecci\u00f3n en tiempo de ejecuci\u00f3n en vuestros clusters, o todo se queda en controles de despliegue?<\/p>\n<hr \/>\n<p dir=\"ltr\"><em>La seguridad en runtime, con Falco y reglas listas para adaptar, es uno de los apartados de mi manual \u201cSeguridad y monitorizaci\u00f3n en Kubernetes\u201d (950 p\u00e1ginas, en espa\u00f1ol). [Descarga la muestra gratuita]([URL de la muestra]) \u00b7 <a href=\"https:\/\/4016705366609.gumroad.com\/l\/seguridad-kubernetes?wanted=true\">Consigue el manual completo<\/a><\/em><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Las Network Policies, Pod Security Admission y un RBAC bien ajustado tienen algo en com\u00fan: son controles preventivos. Deciden qu\u00e9 se puede desplegar y con qui\u00e9n puede hablar cada pod. Pero ninguno te dice qu\u00e9 est\u00e1 pasando dentro de un contenedor que ya est\u00e1 en marcha. Si alguien abre una shell en un pod de [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":3320,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_post_was_ever_published":false},"categories":[5],"tags":[],"class_list":["post-3319","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-tech"],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"https:\/\/i0.wp.com\/djimn.com\/wp-content\/uploads\/2026\/10\/runtime-security-falco.png?fit=1200%2C630&ssl=1","_links":{"self":[{"href":"https:\/\/djimn.com\/index.php\/wp-json\/wp\/v2\/posts\/3319","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/djimn.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/djimn.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/djimn.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/djimn.com\/index.php\/wp-json\/wp\/v2\/comments?post=3319"}],"version-history":[{"count":6,"href":"https:\/\/djimn.com\/index.php\/wp-json\/wp\/v2\/posts\/3319\/revisions"}],"predecessor-version":[{"id":3344,"href":"https:\/\/djimn.com\/index.php\/wp-json\/wp\/v2\/posts\/3319\/revisions\/3344"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/djimn.com\/index.php\/wp-json\/wp\/v2\/media\/3320"}],"wp:attachment":[{"href":"https:\/\/djimn.com\/index.php\/wp-json\/wp\/v2\/media?parent=3319"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/djimn.com\/index.php\/wp-json\/wp\/v2\/categories?post=3319"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/djimn.com\/index.php\/wp-json\/wp\/v2\/tags?post=3319"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}