Kubernetes has become the default deployment platform for modern software. By early 2023, over 60% of organizations were running Kubernetes in production, and that number was growing rapidly. But Kubernetes RBAC (Role-Based Access Control) — the primary mechanism for controlling who can do what in a cluster — remains one of the most misconfigured aspects of the platform.
Misconfigured RBAC doesn't just risk cluster compromise. It creates supply chain risks by allowing unauthorized access to build systems, container registries, secrets, and deployment pipelines running within Kubernetes.
Why RBAC Misconfigurations Are So Common
Kubernetes RBAC is powerful but complex. The system involves Roles, ClusterRoles, RoleBindings, ClusterRoleBindings, ServiceAccounts, and a fine-grained permissions model that covers hundreds of resources and verbs. Getting it right requires understanding both Kubernetes internals and your organization's access requirements.
The most common reason for misconfiguration is simple: getting things working is hard, and the path of least resistance is to grant more permissions than needed.
The cluster-admin Epidemic
The most dangerous pattern is overuse of the cluster-admin ClusterRole, which grants unrestricted access to everything in the cluster. In audits conducted throughout 2022-2023, security researchers consistently found:
- Service accounts running CI/CD pipelines bound to
cluster-admin - Developer accounts with
cluster-adminaccess "because it was easier" - Default service accounts in namespaces with elevated permissions
- Third-party tools installed with
cluster-adminbecause the vendor's docs said to
Each of these represents a potential supply chain compromise path. If a CI/CD pipeline's service account has cluster-admin, anyone who compromises that pipeline can deploy anything to any namespace, access any secret, and modify any resource.
Critical RBAC Mistakes and Fixes
1. Overly Permissive Service Accounts
The mistake: Creating service accounts for applications with broad permissions because the exact required permissions are unknown.
# DON'T DO THIS
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: my-app-admin
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- kind: ServiceAccount
name: my-app
namespace: production
The fix: Start with zero permissions and add only what the application actually needs.
# DO THIS
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: my-app-role
namespace: production
rules:
- apiGroups: [""]
resources: ["configmaps"]
verbs: ["get", "list"]
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list", "watch"]
2. Default Service Account Abuse
The mistake: Not creating dedicated service accounts for pods. When no service account is specified, pods use the default service account in their namespace.
If anyone grants permissions to the default service account, every pod in that namespace inherits those permissions.
The fix: Create dedicated service accounts for each application and explicitly assign them. Set automountServiceAccountToken: false on the default service account.
3. Wildcard Permissions
The mistake: Using wildcards for resources or verbs.
rules:
- apiGroups: ["*"]
resources: ["*"]
verbs: ["*"]
This grants access to everything, including secrets, pod execution, and cluster configuration.
The fix: Never use wildcards in production RBAC rules. Enumerate specific resources and verbs.
4. Unrestricted Secret Access
The mistake: Granting get or list permissions on secrets resources broadly.
Kubernetes secrets contain authentication tokens, API keys, TLS certificates, and other sensitive data. Any service account or user with get secrets permission in a namespace can read every secret in that namespace.
The fix: Use specific resource names when granting secret access:
rules:
- apiGroups: [""]
resources: ["secrets"]
resourceNames: ["my-app-config"]
verbs: ["get"]
5. Pod Exec and Attach Permissions
The mistake: Granting pods/exec or pods/attach permissions to service accounts or users who don't need them.
These permissions allow executing commands inside running containers, which is effectively root access to whatever the container has access to.
The fix: Restrict pods/exec and pods/attach to administrative roles used for debugging, and only when needed. These should never be granted to CI/CD service accounts or application service accounts.
Supply Chain-Specific RBAC Considerations
Protecting Container Registries
If your cluster pulls images from a private registry, the registry credentials are stored as Kubernetes secrets. RBAC must protect these secrets:
- Only the service accounts that need to pull images should have access to registry credentials
- CI/CD service accounts that push images should have separate, scoped credentials
- Registry credentials should be rotated regularly
Securing Build Pipelines
If you run CI/CD within Kubernetes (Jenkins, Tekton, Argo, GitLab runners):
- Build pipeline service accounts should have the minimum permissions needed for their specific tasks
- Different stages of the pipeline should use different service accounts with different permissions
- Build service accounts should not have access to production secrets
Admission Controllers
Complement RBAC with admission controllers that enforce policies on what can be deployed:
- OPA/Gatekeeper: Policy-based admission control
- Kyverno: Kubernetes-native policy engine
- Pod Security Standards: Built-in pod security policies
Admission controllers can enforce requirements like:
- All containers must come from approved registries
- No containers can run as root
- All pods must have resource limits
- All deployments must have specific labels
RBAC Audit Process
Regular Reviews
Conduct quarterly RBAC reviews:
- List all ClusterRoleBindings and identify overly broad permissions
- Review service account usage across namespaces
- Identify unused service accounts and roles
- Verify that CI/CD service accounts follow least privilege
Automated Auditing
Use tools to continuously audit RBAC configurations:
kubectl-who-canto check who has specific permissionsrbac-lookupto identify all permissions for a given subjectkube-benchfor broader security configuration auditing
How Safeguard.sh Helps
Safeguard.sh helps secure Kubernetes environments as part of your software supply chain:
- Container Image Scanning: Safeguard.sh scans container images deployed in your clusters for known vulnerabilities, ensuring that what's running is secure.
- Configuration Auditing: Safeguard.sh audits Kubernetes configurations, including RBAC policies, for security misconfigurations that could lead to supply chain compromise.
- Deployment Verification: Safeguard.sh verifies that deployed containers match their expected SBOMs, detecting unauthorized modifications to container images.
- Supply Chain Visibility: Safeguard.sh provides end-to-end visibility from source code to running containers, ensuring that your Kubernetes deployment is an accurate reflection of your verified build artifacts.
Kubernetes RBAC is the gatekeeper for your cluster. Get it wrong, and everything running in that cluster — your applications, your build pipelines, your secrets — is at risk. Getting it right requires ongoing attention, not just initial configuration.