A Kubernetes role may contain a short list of verbs and resources while enabling a broader operational outcome. Permission to create a workload can expose credentials available to that workload. Permission to change role bindings can change who receives other permissions.
An access review therefore needs to connect the rules to the actions they make possible. Reading each permission in isolation can miss relationships between workloads, identities, and stored secrets.
Resource permissions can compose
Kubernetes documents several privilege-escalation considerations in its RBAC guidance, including access to secrets, workload creation, and powerful role-management permissions. It also cautions that namespace boundaries alone do not provide every form of security isolation. Kubernetes RBAC good practices describe these relationships.
An illustrative application team can create Pods in a shared namespace. If those Pods can use a more privileged service account or mount sensitive material, the team's effective access may exceed the permissions visible in its direct role. The assessment must examine the admission and workload controls that constrain those choices.
Review identities used by running workloads
List service accounts, their bindings, and the workloads that use them. Record whether a workload requires Kubernetes API access at all. Token mounting and identity selection can create authority that an application does not need for its business function.
Cloud identity integrations can add another relationship. A Kubernetes service account may be mapped to a cloud role. That role's permissions belong in the effective access review, even though they are managed outside the cluster's RBAC objects.
Test intended operations and denied alternatives
Use a dedicated test namespace and synthetic secrets. Confirm the operations a representative developer or workload identity is supposed to perform. Then test agreed alternatives, such as selecting another service account or accessing a different namespace, without touching production credentials.
Record the authorization and admission decisions separately. RBAC may allow an API operation that an admission policy later restricts. The evidence needs to show which control enforces the intended boundary and whether that control applies to every relevant path.
Make exceptions and changes reviewable
Cluster-level permissions, emergency roles, and controller identities often require broader access. Document their purpose and owners rather than mixing them into ordinary application roles. Monitor changes that alter bindings or workload identity mappings.
A security assessment can produce an effective-access map for selected identities, with examples of permitted and denied actions. This gives the business a clearer explanation of who can reach application data or infrastructure. It also identifies where a shared namespace, privileged controller, or cloud-role mapping requires more detailed testing before making an isolation claim.
Sources
Kubernetes: Service Accounts. The shared namespace and application team are illustrative.
