Understanding Kubernetes RBAC
Kubernetes Role-Based Access Control (RBAC) is the native authorization mechanism that determines who can perform which actions on which resources in your cluster. While Kubernetes provides the primitives for access control, implementing RBAC effectively requires understanding both the technical components and security best practices.
RBAC operates on four core concepts: Roles define permissions, RoleBindings associate roles with users or groups, ClusterRoles define cluster-wide permissions, and ClusterRoleBindings grant cluster-wide access. Every API request is evaluated against these rules to determine authorization.
RBAC Core Components
- Roles & ClusterRoles
Define what actions can be performed on which resources
- RoleBindings & ClusterRoleBindings
Associate roles with subjects (users, groups, service accounts)
- Service Accounts
Identities for applications and automated processes
Common RBAC Challenges
Organizations implementing Kubernetes RBAC face several recurring challenges. Understanding these pitfalls helps you design more secure and maintainable access control systems.
1. Overly Permissive Roles
The most common mistake is granting excessive permissions. Teams often start with broad permissions for convenience and never narrow them down. A developer who only needs to view pod logs shouldn't have cluster-admin access, yet this pattern is surprisingly common.
2. Service Account Sprawl
Every pod gets a service account, and without careful management, you end up with hundreds of service accounts with unclear permissions. This makes auditing nearly impossible and increases the attack surface when a pod is compromised.
3. Static Long-Lived Credentials
Default Kubernetes service account tokens never expire. If these tokens leak or a service account is compromised, the credential remains valid indefinitely. This violates the principle of least-privilege duration.
4. Namespace Isolation Failures
Teams assume namespaces provide security isolation, but RBAC misconfiguration can grant cross-namespace access. A single overly broad ClusterRole can undermine your entire namespace security strategy.
Common Anti-Pattern
# DON'T DO THIS - Grants cluster-admin to a service account
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: dangerous-binding
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- kind: ServiceAccount
name: my-app
namespace: productionThis grants full cluster access to a single application. If the app is compromised, attackers have complete control over the entire cluster.
RBAC Best Practices
1. Principle of Least Privilege
Grant only the minimum permissions required for a specific task. Start with zero permissions and add only what's needed. This requires understanding what your applications actually do.
# Good: Minimal role for pod log viewer
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: production
name: pod-log-reader
rules:
- apiGroups: [""]
resources: ["pods", "pods/log"]
verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: developer-log-access
namespace: production
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: pod-log-reader
subjects:
- kind: User
name: jane@example.com
apiGroup: rbac.authorization.k8s.io2. Use Namespace-Scoped Roles When Possible
Prefer Roles over ClusterRoles unless you truly need cluster-wide access. Namespace-scoped roles limit the blast radius of compromised credentials.
3. Separate Read and Write Permissions
Create distinct roles for viewing versus modifying resources. Most users need read access; reserve write permissions for authorized operators and automation.
# Read-only role for developers
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: production
name: developer-readonly
rules:
- apiGroups: ["", "apps", "batch"]
resources: ["pods", "deployments", "jobs", "services"]
verbs: ["get", "list", "watch"]
- apiGroups: [""]
resources: ["pods/log"]
verbs: ["get", "list"]
---
# Write role for SRE team only
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: production
name: sre-operator
rules:
- apiGroups: ["", "apps"]
resources: ["deployments", "replicasets"]
verbs: ["get", "list", "watch", "update", "patch"]
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list", "delete"] # Can delete pods but not create4. Avoid Wildcards in Production
Wildcards (*) in RBAC rules create overly broad permissions. Explicitly list the resources and verbs needed.
# Bad: Wildcard permissions
rules:
- apiGroups: ["*"]
resources: ["*"]
verbs: ["*"]
# Good: Explicit permissions
rules:
- apiGroups: ["apps"]
resources: ["deployments", "statefulsets"]
verbs: ["get", "list", "watch", "update"]5. Use Groups for User Management
Bind roles to groups rather than individual users. This makes permission management scalable and integrates cleanly with identity providers.
# Bind role to a group from your IdP
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: developers-readonly
namespace: production
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: developer-readonly
subjects:
- kind: Group
name: developers@example.com
apiGroup: rbac.authorization.k8s.ioCommon Role Patterns
Developer Role
Developers need visibility into their applications but shouldn't modify production infrastructure directly.
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: production
name: developer
rules:
# View application resources
- apiGroups: ["", "apps"]
resources: ["pods", "services", "deployments", "replicasets"]
verbs: ["get", "list", "watch"]
# View logs and exec into pods for debugging
- apiGroups: [""]
resources: ["pods/log", "pods/exec"]
verbs: ["get", "create"]
# View ConfigMaps (but not Secrets)
- apiGroups: [""]
resources: ["configmaps"]
verbs: ["get", "list"]
# Port-forward for local debugging
- apiGroups: [""]
resources: ["pods/portforward"]
verbs: ["create"]CI/CD Deployment Role
Automated deployment systems need specific permissions to update applications without full cluster access.
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: production
name: cicd-deployer
rules:
# Manage deployments
- apiGroups: ["apps"]
resources: ["deployments"]
verbs: ["get", "list", "watch", "create", "update", "patch"]
# View and create ReplicaSets (created by Deployments)
- apiGroups: ["apps"]
resources: ["replicasets"]
verbs: ["get", "list", "watch"]
# Manage ConfigMaps for configuration
- apiGroups: [""]
resources: ["configmaps"]
verbs: ["get", "list", "create", "update", "patch"]
# View pods to verify deployment status
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list", "watch"]SRE Operator Role
SRE teams need broader permissions for incident response and maintenance, but still scoped to specific namespaces.
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: production
name: sre-operator
rules:
# Full control over workloads
- apiGroups: ["apps"]
resources: ["deployments", "statefulsets", "daemonsets", "replicasets"]
verbs: ["*"]
# Pod management for troubleshooting
- apiGroups: [""]
resources: ["pods", "pods/log", "pods/exec"]
verbs: ["*"]
# ConfigMap and Secret management
- apiGroups: [""]
resources: ["configmaps", "secrets"]
verbs: ["*"]
# Service and ingress management
- apiGroups: ["", "networking.k8s.io"]
resources: ["services", "ingresses"]
verbs: ["*"]
# View events for debugging
- apiGroups: [""]
resources: ["events"]
verbs: ["get", "list", "watch"]Service Account Security
Service accounts are the most common source of RBAC vulnerabilities. Every pod runs with a service account identity, making them critical to secure properly.
Create Dedicated Service Accounts
Never use the default service account for applications. Create dedicated service accounts with specific permissions for each workload.
# Create service account for specific application
apiVersion: v1
kind: ServiceAccount
metadata:
name: web-app
namespace: production
---
# Create minimal role for this application
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: web-app-role
namespace: production
rules:
- apiGroups: [""]
resources: ["configmaps"]
resourceNames: ["web-app-config"] # Only specific ConfigMap
verbs: ["get"]
---
# Bind role to service account
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: web-app-binding
namespace: production
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: web-app-role
subjects:
- kind: ServiceAccount
name: web-app
namespace: production
---
# Use in Pod spec
apiVersion: v1
kind: Pod
metadata:
name: web-app
namespace: production
spec:
serviceAccountName: web-app
automountServiceAccountToken: false # Only mount if needed
containers:
- name: app
image: web-app:v1.0.0Disable Automatic Token Mounting
If your application doesn't need to call the Kubernetes API, disable automatic token mounting to reduce attack surface.
Use Bound Service Account Tokens
Enable projected volume tokens with audience and time-bound restrictions for enhanced security.
apiVersion: v1
kind: Pod
metadata:
name: secure-app
spec:
serviceAccountName: web-app
containers:
- name: app
image: web-app:v1.0.0
volumeMounts:
- name: token
mountPath: /var/run/secrets/tokens
readOnly: true
volumes:
- name: token
projected:
sources:
- serviceAccountToken:
path: token
expirationSeconds: 3600 # 1-hour expiry
audience: apiEnhancing RBAC with TigerAccess
While Kubernetes RBAC provides the foundation for access control, TigerAccess adds critical security layers that native RBAC lacks: short-lived certificates, audit logging, session recording, and just-in-time access controls.
Certificate-Based Authentication
TigerAccess replaces static kubeconfig files and long-lived service account tokens with short-lived certificates. Users authenticate through TigerAccess and receive temporary Kubernetes certificates that automatically expire.
# Login and get 4-hour Kubernetes certificate
tac login
# Access cluster through TigerAccess
tac kube get pods -n production
# Behind the scenes, TigerAccess:
# 1. Verifies your identity and MFA
# 2. Checks RBAC policies
# 3. Issues short-lived Kubernetes certificate
# 4. Logs all access attempts
# 5. Records session for audit
# Certificate automatically expires after TTL
# No need to manually revoke accessDynamic RBAC with Access Requests
Instead of granting permanent elevated permissions, TigerAccess enables just-in-time access requests that temporarily elevate privileges for specific tasks.
# Developer requests elevated access for deployment
tac request create \
--roles=sre-operator \
--resource=k8s/production-cluster \
--reason="Emergency rollback of v2.1.0" \
--duration=1h
# Manager approves via Slack/Web UI
# Developer gets temporary elevated access
# Access automatically revoked after 1 hour
# Full audit trail maintainedComprehensive Audit Logging
TigerAccess captures complete audit trails including who accessed what resource, when, why, and what actions they performed. This goes beyond Kubernetes audit logs to provide compliance-ready reporting.
TigerAccess Audit Context
- Who: User identity from SSO (not just certificate CN)
- What: Exact kubectl commands and API calls
- When: Precise timestamps with timezone
- Where: Source IP, device fingerprint, location
- Why: Access request reason and approver
- How: MFA method, certificate details
- Outcome: Success/failure with error details
Session Recording for kubectl
TigerAccess can record entire kubectl sessions, providing video-like playback of what commands were executed and what data was accessed. This is invaluable for security investigations and compliance audits.
Integration with Native RBAC
TigerAccess doesn't replace Kubernetes RBAC—it enhances it. Your existing Role and RoleBinding definitions continue to work, but TigerAccess adds an authorization layer that enforces additional policies before issuing certificates.
# TigerAccess authorization flow:
# 1. User authenticates with SSO
# 2. TigerAccess checks user's assigned TigerAccess roles
# 3. TigerAccess maps to Kubernetes RBAC groups
# 4. Issues certificate with appropriate groups claim
# 5. Kubernetes API validates certificate and applies RBAC
# 6. TigerAccess logs all API calls
# Example: Developer role mapping
# TigerAccess Role: developer
# K8s Groups: ["developers", "production-viewers"]
# K8s RoleBinding grants "developer-readonly" role to "developers" group
# Result: Temporary certificate with proper RBAC groupsSecurity Considerations
Regular RBAC Audits
Implement periodic reviews of RBAC policies to identify overly permissive roles, unused bindings, and privilege creep. Use tools like kubectl-who-can to understand effective permissions.
# Audit who can perform sensitive operations
kubectl-who-can delete pods -n production
kubectl-who-can get secrets --all-namespaces
kubectl-who-can create clusterroles
# TigerAccess provides built-in RBAC analyzer
tacctl rbac audit --cluster=production
# Shows: overly permissive roles, unused bindings,
# privilege escalation paths, compliance violationsPrevent Privilege Escalation
Ensure that roles cannot be used to grant additional permissions. The "escalate" and "bind" verbs on roles/clusterroles are particularly dangerous.
# Dangerous: Allows creating arbitrary RoleBindings
rules:
- apiGroups: ["rbac.authorization.k8s.io"]
resources: ["rolebindings"]
verbs: ["create", "update"]
# This user could bind cluster-admin to themselves!
# Safer: Restrict to specific roles
rules:
- apiGroups: ["rbac.authorization.k8s.io"]
resources: ["rolebindings"]
verbs: ["create", "update"]
# Must also have "bind" permission on the specific role
resourceNames: ["developer-readonly"]Protect Critical Resources
Use resource names to restrict access to specific critical resources like production secrets or security policies.
# Allow access to specific secrets only
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: app-secret-reader
namespace: production
rules:
- apiGroups: [""]
resources: ["secrets"]
resourceNames:
- app-database-creds
- app-api-keys
verbs: ["get"]Monitor for Anomalous Access
Enable Kubernetes audit logging and monitor for unusual patterns like after-hours access, bulk resource queries, or privilege escalation attempts.
TigerAccess Anomaly Detection
TigerAccess automatically detects and alerts on suspicious Kubernetes access patterns:
- • Access from unusual geographic locations
- • Bulk secret reads or elevated privilege usage
- • Commands executed during off-hours
- • Rapid permission escalation attempts
- • Service account token exfiltration patterns
Conclusion
Kubernetes RBAC is essential for cluster security, but it requires careful design and ongoing management. By following the principle of least privilege, using namespace-scoped roles, creating dedicated service accounts, and implementing regular audits, you can build a secure foundation for cluster access.
However, native RBAC has limitations: static credentials, limited audit context, no session recording, and complex privilege management. This is where TigerAccess adds value—short-lived certificates eliminate static credentials, comprehensive audit logging captures complete access context, session recording provides visibility into actual operations, and just-in-time access reduces standing privileges.
The combination of well-designed Kubernetes RBAC and TigerAccess's enhanced security controls creates defense-in-depth for your cluster access management. Start with solid RBAC fundamentals, then layer on TigerAccess for enterprise-grade security, compliance, and operational visibility.