{"id":291,"date":"2026-08-09T08:15:18","date_gmt":"2026-08-09T08:15:18","guid":{"rendered":"https:\/\/wp.spain2.com\/your-kubernetes-rbac-is-wide-open-how-smbs-can-implement-least-privilege-access-and-workload-identity\/"},"modified":"2026-08-09T08:15:18","modified_gmt":"2026-08-09T08:15:18","slug":"your-kubernetes-rbac-is-wide-open-how-smbs-can-implement-least-privilege-access-and-workload-identity","status":"publish","type":"post","link":"https:\/\/wp.spain2.com\/es\/your-kubernetes-rbac-is-wide-open-how-smbs-can-implement-least-privilege-access-and-workload-identity\/","title":{"rendered":"Tu RBAC de Kubernetes Est\u00e1 Abierto de Par en Par: C\u00f3mo las PYMEs Pueden Implementar Acceso de M\u00ednimo Privilegio e Identidad de Cargas de Trabajo"},"content":{"rendered":"

Ask most SMB engineering teams how many people can run kubectl delete ns production<\/code> on their cluster. The honest answer, after a long pause, is usually: “\u2026everyone with a kubeconfig.”<\/em><\/p>\n

It is the most common Kubernetes security gap we see in small companies: cluster-admin everywhere<\/strong>. One leaked CI token, one stolen laptop, one disgruntled ex-employee with a cached kubeconfig \u2014 and an attacker has the same power as the platform team. Auditors and SOC 2 assessors are increasingly asking for proof of least-privilege access, and most SMBs cannot produce it.<\/p>\n

The good news: fixing this is a two-week project, not a platform-engineering epic. In this guide you will audit your current access, build a least-privilege RBAC model, replace long-lived credentials with workload identity, and automate enforcement so it stays fixed.<\/p>\n

Audit First: Find Every cluster-admin Before You Change Anything<\/h2>\n

You cannot secure what you cannot see. Start by listing every subject (user or service account) bound to the cluster-admin<\/code> ClusterRole:<\/p>\n

kubectl get clusterrolebinding -o json | \\\n  jq -r '.items[] | select(.roleRef.name == \"cluster-admin\") | \n    .subjects[]? | \"\\(.kind):\\(.name) (namespace: \\(.namespace \/\/ \"N\/A\"))\"'<\/code><\/pre>\n
Then check what a specific identity can actually do \u2014 for example, the service account your CI pipeline uses:<\/p>\n
# What can the CI deployer service account do, cluster-wide?\nkubectl auth can-i --list \\\n  --as=system:serviceaccount:ci:deployer \\\n  --namespace=production | head -30\n\n# Who can create pods in production? (reverse lookup)\nkubectl-who-can create pods -n production<\/code><\/pre>\n
(kubectl-who-can<\/code> and rbac-lookup<\/code> are tiny open-source plugins that invert RBAC rules into “who can do X” answers \u2014 invaluable for audits.)<\/p>\n
Common findings in SMB clusters: the bootstrap admin user still in use, service accounts with automountServiceAccountToken: true<\/code> in namespaces that need no API access, and CI credentials with cluster-wide *<\/code> permissions because “it was easier.” Write them all down \u2014 that list is your work backlog.<\/p>\n
Build a Least-Privilege RBAC Model in 30 Minutes<\/h2>\n
The model that fits most SMBs is simple: namespace-scoped Roles, three tiers of access, and group-based bindings<\/strong>.<\/p>\n