{"id":3302,"date":"2026-10-11T20:33:47","date_gmt":"2026-10-11T18:33:47","guid":{"rendered":"https:\/\/djimn.com\/?p=3302"},"modified":"2026-10-11T20:33:47","modified_gmt":"2026-10-11T18:33:47","slug":"por-que-la-mayoria-de-clusters-de-kubernetes-siguen-con-la-red-plana","status":"publish","type":"post","link":"https:\/\/djimn.com\/index.php\/2026\/10\/11\/por-que-la-mayoria-de-clusters-de-kubernetes-siguen-con-la-red-plana\/","title":{"rendered":"Por qu\u00e9 la mayor\u00eda de clusters de Kubernetes siguen con la red plana"},"content":{"rendered":"<p dir=\"ltr\">Por defecto, en un cluster de Kubernetes cualquier pod puede hablar con cualquier otro pod. No hay excepciones ni fricci\u00f3n, y no hace falta configurar nada. Es maravilloso para desarrollar r\u00e1pido, y es exactamente el motivo por el que, cuando algo se compromete, no se queda contenido: se mueve.<\/p>\n<p dir=\"ltr\">Llevo bastante tiempo viendo el mismo patr\u00f3n en clusters de producci\u00f3n. Hay NetworkPolicies en dos o tres namespaces \u201cimportantes\u201d, y el resto sigue con red plana porque \u201cya lo haremos cuando toque\u201d. Nunca toca.<\/p>\n<p dir=\"ltr\">Lo que suelo recomendar no es microsegmentar todo de golpe. Eso es inviable y genera tanto rechazo que se abandona a la primera incidencia. Es mejor un enfoque incremental:<\/p>\n<p dir=\"ltr\"><strong>Paso 1: default deny por namespace, empezando por los nuevos.<\/strong> Cualquier namespace que se cree a partir de ahora nace con una NetworkPolicy de deny-all como base. Es mucho m\u00e1s f\u00e1cil imponer esto desde el primer d\u00eda que a\u00f1adirlo despu\u00e9s.<\/p>\n<p dir=\"ltr\"><strong>Paso 2: egress antes que ingress.<\/strong> Casi todo el esfuerzo de seguridad se pone en controlar qui\u00e9n entra a un pod. Pero si un pod se compromete, lo que de verdad limita el da\u00f1o es a d\u00f3nde puede <em>salir<\/em>: otros namespaces, Internet o el metadata service del proveedor cloud. Controlar el egress suele dar m\u00e1s seguridad con el mismo esfuerzo.<\/p>\n<p dir=\"ltr\"><strong>Paso 3: los namespaces con datos sensibles primero.<\/strong> Si tienes que priorizar, empieza por donde viven la base de datos o el servicio de pagos, no por el namespace de un dashboard interno.<\/p>\n<p dir=\"ltr\"><strong>Paso 4: verificar, no asumir.<\/strong> Una NetworkPolicy mal escrita da una falsa sensaci\u00f3n de seguridad. Antes de darla por buena, intenta la conexi\u00f3n que deber\u00eda estar bloqueada y confirma que efectivamente falla.<\/p>\n<p dir=\"ltr\">Ninguna herramienta de escaneo te va a avisar de que tu cluster tiene la red plana con la urgencia con la que deber\u00eda sonar esa alarma. Es una decisi\u00f3n que hay que tomar activamente.<\/p>\n<p dir=\"ltr\">\u00bfTen\u00e9is NetworkPolicies desplegadas en todos los namespaces de producci\u00f3n, o solo en los que \u201cm\u00e1s preocupan\u201d?<\/p>\n<hr \/>\n<p dir=\"ltr\"><em>El cap\u00edtulo completo de Network Policies, con manifiestos de default deny y control de egress listos para adaptar, est\u00e1 incluido en la muestra gratuita de mi manual \u201cSeguridad y monitorizaci\u00f3n en Kubernetes\u201d. [Descarga la muestra gratuita] en https:\/\/djimn.com\u00a0 \u00b7 <a href=\"https:\/\/4016705366609.gumroad.com\/l\/seguridad-kubernetes?wanted=true\">Consigue el manual completo (950 p\u00e1ginas)<\/a><\/em><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Por defecto, en un cluster de Kubernetes cualquier pod puede hablar con cualquier otro pod. No hay excepciones ni fricci\u00f3n, y no hace falta configurar nada. Es maravilloso para desarrollar r\u00e1pido, y es exactamente el motivo por el que, cuando algo se compromete, no se queda contenido: se mueve. Llevo bastante tiempo viendo el mismo [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":3304,"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":[60],"class_list":["post-3302","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-tech","tag-arquitecturadesoftware-cloudcomputing-devops-sre-monitorizacion-seguridad-aws-azure-gcp-finops"],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"https:\/\/i0.wp.com\/djimn.com\/wp-content\/uploads\/2026\/10\/red-plana-kubernetes.png?fit=1200%2C630&ssl=1","_links":{"self":[{"href":"https:\/\/djimn.com\/index.php\/wp-json\/wp\/v2\/posts\/3302","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=3302"}],"version-history":[{"count":1,"href":"https:\/\/djimn.com\/index.php\/wp-json\/wp\/v2\/posts\/3302\/revisions"}],"predecessor-version":[{"id":3303,"href":"https:\/\/djimn.com\/index.php\/wp-json\/wp\/v2\/posts\/3302\/revisions\/3303"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/djimn.com\/index.php\/wp-json\/wp\/v2\/media\/3304"}],"wp:attachment":[{"href":"https:\/\/djimn.com\/index.php\/wp-json\/wp\/v2\/media?parent=3302"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/djimn.com\/index.php\/wp-json\/wp\/v2\/categories?post=3302"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/djimn.com\/index.php\/wp-json\/wp\/v2\/tags?post=3302"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}