Kubernetes / Intermediate: rollout, policy, and evidence / Lesson 10
RBAC and service identities
Trace authenticated identity through roles and bindings, then evaluate indirect privilege and least-authority design.
On this page
Lesson goals
- Explain the model, assumptions, and boundaries of rbac and service identities.
- Interpret both examples and distinguish declared intent from established evidence.
- Diagnose the listed failures and justify the worked recovery decisions without executing cluster operations.
Authentication and authorization are separate
Authentication identifies a user or workload; authorization decides whether an action on a resource is permitted. Admission then applies additional rules to relevant requests. A valid ServiceAccount token is not permission to read every Secret. Kubernetes supports several authentication and authorization mechanisms, so inspect the selected cluster policy rather than assuming RBAC is the only decision. Keep principal, verb, API group, resource, namespace, and relevant subresource explicit. Troubleshooting an authorization denial by replacing the identity with a cluster administrator hides the missing contract and can create a much larger security problem.
Read roles and bindings together
A Role defines permissions in a namespace; a ClusterRole defines reusable or cluster-scoped permissions. A RoleBinding can bind a ClusterRole within its namespace, while a ClusterRoleBinding grants at cluster scope. The first example defines a narrow Role for reading ConfigMaps and does not grant it to anyone. A matching binding and authenticated identity are separate requirements. RBAC permissions are additive and do not provide an explicit deny rule. Review all applicable grants before claiming a principal is restricted, and avoid wildcards that silently include future resources or verbs.
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata: {name: config-reader, namespace: training}
rules:
- apiGroups: [""]
resources: [configmaps]
verbs: [get, list]
The Role permits selected ConfigMap reads only when bound to an identity. It contains no Secret grant, binding, or cluster-wide authority and is never applied.
Evaluate indirect access paths
Creating or modifying workloads can expose mounted credentials, choose service identities, or run code with permissions not visible in a simple read rule. Access to exec, attach, logs, or port-forward subresources also has consequences and belongs in review. Secret list and watch access can disclose values, not merely object names. The second synthetic matrix separates observation from mutation and credential exposure. Do not infer a safe tenant boundary from a namespace label or from denying one direct Secret verb. Use admission, workload security, and identity restrictions together with authorization.
capability review consequence
read ConfigMap nonsecret configuration visibility
list Secret potential sensitive-value disclosure
create Pod indirect mounted-credential access
change RoleBinding authorization model modification
exec into container workload execution and data access
The table describes risks, not actual permissions or executed operations. Final authority depends on all authorization and admission controls in the selected environment.
Protect escalation and credential lifecycle
Role creation, binding changes, impersonation, and special escalation permissions can alter the authority model and need tightly controlled ownership. Prefer dedicated ServiceAccounts for distinct responsibilities and review automatic token mounting when API access is unnecessary. Projected tokens have audience and lifetime behavior that consumers must validate; copying them into durable configuration defeats that design. External workload identity integration has separate provider requirements. Keep human emergency access accountable and time limited. A static binding review does not prove that old credentials have been revoked or that a compromised workload stopped using them.
Verify the intended denial as well as allowance
A permission test should establish both required allowed actions and prohibited neighboring actions for the actual identity and scope. Use an authorized isolated environment and safe fixtures rather than testing administrative access against a real cluster. Record the source of each grant and periodically review unused permissions. No authorization query, token decoding, impersonation, or cluster request is performed in this lesson. YAML parsing verifies syntax only. Least privilege is a maintained relationship between task, identity, resource, and policy, not a role name that remains safe after responsibilities change.
Common errors and fixes
A Role is assumed to grant access by itself
- Why it happens
- Binding and principal identity were omitted.
- How to fix it
- Review role, binding, subject, and request scope together.
- Prevent it next time
- Keep an explicit permission matrix for each workload.
Removing one grant does not deny an action
- Why it happens
- Another additive RBAC rule still allows it.
- How to fix it
- Inspect every applicable binding and role.
- Prevent it next time
- Review effective authority rather than one manifest.
A read-restricted workload still exposes a Secret
- Why it happens
- Workload creation or execution provided indirect access.
- How to fix it
- Constrain workload, identity, mount, and admission capabilities.
- Prevent it next time
- Threat-model privilege paths across controls.
Check your understanding
1. Can a RoleBinding refer to a ClusterRole while granting only within one namespace?
Show worked solution
Yes. The bindingโs namespace constrains applicable namespaced permissions, while the role supplies rules. Compare this with ClusterRoleBinding and review resource scope. The word ClusterRole alone does not establish where a particular binding grants access.
2. A workload needs one configuration read. Is cluster-admin an acceptable shortcut?
Show worked solution
No. Identify the exact identity, namespace, resource, and verbs, grant only that contract, and verify prohibited actions remain denied. Broad administrative authority turns a small application defect into a cluster-wide risk and obscures future permission review.
Key takeaways
- Authentication identifies a user or workload; authorization decides whether an action on a resource is permitted.
- Creating or modifying workloads can expose mounted credentials, choose service identities, or run code with permissions not visible in a simple read rule.
- A permission test should establish both required allowed actions and prohibited neighboring actions for the actual identity and scope.