Kubernetes RBAC and service accounts: identity, scope and privilege paths
Understand Roles, ClusterRoles and bindings, then grant a workload the minimum Kubernetes API access it needs. Explain short-lived service-account tokens and indirect privilege escalation.
TL;DR: A service account identifies a workload to the Kubernetes API; RBAC bindings grant actions on resources within a scope. Review the full privilege path, because permission to create a Pod can expose credentials or identities beyond what a simple Secret-read rule suggests.
Authentication and authorization are separate steps
A service account belongs to a namespace. A workload can use a service-account token to authenticate, and the API server evaluates whether the resulting identity may perform the requested action. A valid token does not imply permission to list Pods, read Secrets or change workloads.
Roles describe namespaced permissions. ClusterRoles can describe cluster-scoped permissions and reusable sets of namespaced permissions. A RoleBinding can refer to a ClusterRole while granting applicable permissions only within the binding's namespace. A ClusterRoleBinding grants the referenced permissions cluster-wide.
The RBAC reference documents these combinations. Permissions are additive; an extra binding can expand effective access beyond the narrow Role you happen to be reviewing.
Network access to the API and API authorization are different controls. A network policy cannot by itself express all resource-level RBAC rules.
Worked access requirement: one report controller
Suppose a controller needs to observe Jobs in namespace reports and publish status to a separate application API. It does not need to read arbitrary Kubernetes Secrets or modify cluster nodes.
Start with the actual API operations used by its client. Reading existing objects and watching changes can require get, list and watch on Jobs in the batch API group. Bind that narrow permission to its dedicated service account in reports. Keep its external application credential under a separate lifecycle and authorization policy.
Test both allowed and denied operations using an authorized test setup. Verify it can observe Jobs in reports, cannot read Secrets and cannot list Jobs in an unrelated namespace. Inspect other bindings before declaring the test identity restricted.
| Requirement | Appropriate starting scope | Overgrant to challenge |
|---|---|---|
| Observe Jobs in one namespace | Namespaced binding for read/watch verbs | Cluster administrator |
| Read one configured object | Specific resource and name where supported | Read every Secret in the namespace |
| Manage cluster-scoped resources | Explicitly reviewed cluster permission | Reusing a broad deployment identity |
| No Kubernetes API calls | Avoid unnecessary token mounting | Default token present without a consumer |
Resource-name restrictions have operation-specific limits, particularly for list/watch selectors and creation. Check the actual API behavior rather than assuming one resourceNames entry constrains every verb equally.
Prefer bounded token lifetime
Modern Kubernetes supports time-bound tokens through the TokenRequest mechanism and projected service-account token volumes. Tokens can carry an audience and expiry; consumers must support rotation. Long-lived manually created token Secrets should not be the default solution to an integration problem.
The service-account documentation explains token mechanisms and identity behavior. Disable automatic token mounting where the workload has no need for API credentials, while accounting for any explicitly projected tokens the application does require.
A Kubernetes token is not automatically a cloud credential. Workload identity federation can exchange a trusted token under a separately configured cloud trust policy. Both the Kubernetes identity and the cloud authorization need review.
Direct permissions can hide indirect power
A user who can create workloads in a namespace may be able to choose service accounts, mount accessible credentials or run code with permissions available there, subject to admission and other controls. Reading a Pod specification can also reveal operational information even when Secret values are not included.
The RBAC good-practice guide discusses escalation risks. Namespace isolation, admission restrictions and credential scope must support the RBAC design. Denying one direct Secret-read operation does not prove the identity has no route to that secret.
Audit permission changes with the same care as application code. A wildcard can begin covering new resources introduced later, so broad rules can grow in effect without another edit to the binding.
Check the effective permission
Does binding a ClusterRole always grant cluster-wide access? No. A RoleBinding scopes applicable permissions to its namespace; a ClusterRoleBinding has cluster-wide scope.
Does a service account require cluster-admin to authenticate? No. Authentication identifies it. Authorization is granted separately for the required operations.
What should happen when a projected token rotates? The client should read and use the current credential through its supported mechanism. Caching one token forever creates an avoidable outage when the old token expires.
Compare that additive permission model with RBAC, ABAC and least privilege, including the risk of allowing a principal to edit its own authorization attributes.