{"id":3225,"date":"2026-09-14T16:32:21","date_gmt":"2026-09-14T14:32:21","guid":{"rendered":"https:\/\/djimn.com\/?p=3225"},"modified":"2026-09-14T16:32:21","modified_gmt":"2026-09-14T14:32:21","slug":"los-errores-de-rbac-que-me-sigo-encontrando-en-produccion","status":"publish","type":"post","link":"https:\/\/djimn.com\/index.php\/2026\/09\/14\/los-errores-de-rbac-que-me-sigo-encontrando-en-produccion\/","title":{"rendered":"Los errores de RBAC que me sigo encontrando en producci\u00f3n"},"content":{"rendered":"<p dir=\"ltr\">Cada vez que entro a auditar un cluster de Kubernetes nuevo, hago la misma prueba: <code>kubectl auth can-i --list --as=system:serviceaccount:&lt;ns&gt;:&lt;sa&gt;<\/code> sobre dos o tres service accounts al azar. Casi siempre encuentro lo mismo.<\/p>\n<p dir=\"ltr\"><strong>1. ClusterRoleBindings que nadie recuerda por qu\u00e9 existen.<\/strong> Alguien necesit\u00f3 desbloquear un despliegue hace meses, at\u00f3 un ServiceAccount a <code>cluster-admin<\/code> &#8220;solo para probar&#8221;, y ese binding sigue vivo. Nadie lo revisa porque no rompe nada \u2014 hasta que ese ServiceAccount se ve comprometido y el radio de explosi\u00f3n es literalmente todo el cluster.<\/p>\n<p dir=\"ltr\"><strong>2. Roles con <code>resources: [\"*\"]<\/code> y <code>verbs: [\"*\"]<\/code> para evitar depurar permisos.<\/strong> Es m\u00e1s r\u00e1pido dar todo que averiguar qu\u00e9 necesita realmente un Operator o un Job. El problema es que &#8220;m\u00e1s r\u00e1pido hoy&#8221; se convierte en &#8220;imposible de auditar en seis meses&#8221;.<\/p>\n<p dir=\"ltr\"><strong>3. Service accounts que comparten permisos entre namespaces sin necesidad.<\/strong> Un RoleBinding que deber\u00eda vivir en un namespace aparece replicado en cinco, normalmente copiado-pegado de un manifiesto de otro entorno.<\/p>\n<p dir=\"ltr\"><strong>4. Nadie audita qu\u00e9 ClusterRoles agregan a <code>admin<\/code> o <code>edit<\/code> v\u00eda <code>aggregationRule<\/code>.<\/strong> Es una de las formas m\u00e1s silenciosas de que un permiso &#8220;inofensivo&#8221; acabe dando acceso amplio sin que quede expl\u00edcito en ning\u00fan manifiesto que revises directamente.<\/p>\n<p dir=\"ltr\">La checklist que aplico ahora antes de dar el visto bueno a cualquier RBAC nuevo:<\/p>\n<ul dir=\"ltr\">\n<li>\u00bfEste ServiceAccount necesita permisos de cluster, o le basta con un namespace?<\/li>\n<li>\u00bfPuedo sustituir <code>[\"*\"]<\/code> por la lista real de recursos\/verbos que usa el Operator o la app?<\/li>\n<li>\u00bfEste binding tiene fecha de caducidad o una raz\u00f3n documentada para existir?<\/li>\n<li>\u00bfHay alg\u00fan ClusterRole con <code>aggregationRule<\/code> que est\u00e9 ampliando permisos sin que se vea a simple vista?<\/li>\n<\/ul>\n<p dir=\"ltr\">Ninguna de estas pr\u00e1cticas es nueva. El problema nunca es no saberlo \u2014 es que revisar RBAC no es urgente hasta el d\u00eda que s\u00ed lo es.<\/p>\n<p dir=\"ltr\">\u00bfCu\u00e1l de estos os suena m\u00e1s a &#8220;eso lo tenemos nosotros&#8221;?<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Cada vez que entro a auditar un cluster de Kubernetes nuevo, hago la misma prueba: kubectl auth can-i &#8211;list &#8211;as=system:serviceaccount:&lt;ns&gt;:&lt;sa&gt;&#8230;<\/p>\n","protected":false},"author":1,"featured_media":0,"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,"_joinchat":{"telephone":"+34677599864"},"footnotes":"","jetpack_post_was_ever_published":false},"categories":[5],"tags":[60],"class_list":["post-3225","post","type-post","status-publish","format-standard","hentry","category-tech","tag-arquitecturadesoftware-cloudcomputing-devops-sre-monitorizacion-seguridad-aws-azure-gcp-finops"],"jetpack_likes_enabled":true,"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/djimn.com\/index.php\/wp-json\/wp\/v2\/posts\/3225","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=3225"}],"version-history":[{"count":1,"href":"https:\/\/djimn.com\/index.php\/wp-json\/wp\/v2\/posts\/3225\/revisions"}],"predecessor-version":[{"id":3226,"href":"https:\/\/djimn.com\/index.php\/wp-json\/wp\/v2\/posts\/3225\/revisions\/3226"}],"wp:attachment":[{"href":"https:\/\/djimn.com\/index.php\/wp-json\/wp\/v2\/media?parent=3225"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/djimn.com\/index.php\/wp-json\/wp\/v2\/categories?post=3225"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/djimn.com\/index.php\/wp-json\/wp\/v2\/tags?post=3225"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}