Why RBAC matters in Kubernetes - Performance Analysis
We want to understand how the time it takes to check permissions in Kubernetes grows as the number of users and roles increases.
This helps us see why RBAC performance matters when managing access.
Analyze the time complexity of the following RBAC permission check process.
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: read-pods
namespace: default
subjects:
- kind: User
name: alice
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io
This snippet binds user 'alice' to the 'pod-reader' role in the default namespace, allowing permission checks for pod reading.
When Kubernetes checks if a user can perform an action, it:
- Primary operation: Searches through all RoleBindings and ClusterRoleBindings to find matching subjects and roles.
- How many times: It repeats this search for each permission check requested by users or services.
As the number of RoleBindings and ClusterRoleBindings grows, the permission check takes longer.
| Input Size (number of bindings) | Approx. Operations |
|---|---|
| 10 | 10 permission checks |
| 100 | 100 permission checks |
| 1000 | 1000 permission checks |
Pattern observation: The time to check permissions grows roughly in direct proportion to the number of bindings.
Time Complexity: O(n)
This means permission checks take longer as the number of roles and bindings increases, growing in a straight line.
[X] Wrong: "Permission checks are instant no matter how many roles exist."
[OK] Correct: Each check must search through roles and bindings, so more roles mean more work and longer checks.
Understanding how RBAC scales helps you explain real-world security and performance trade-offs in Kubernetes.
"What if Kubernetes cached permission checks? How would that change the time complexity?"