Examples in this article are illustrative, not customer case studies. Product availability and coverage are described on the linked capability pages.
A Pod can run the right image while carrying credentials its application does not need. This guide builds a service-account review around the running workload, the access it requires and the evidence needed to reduce that access safely.
Consider a fictional payments namespace containing a checkout API and a reconciliation worker. Both use the namespace’s default service account because their original deployment templates never selected another identity. The worker needs to inspect a particular Kubernetes resource; the checkout API only talks to a database. Treat this as a review scenario, not a report about a customer or a tested production configuration.
Kubernetes service accounts need a workload inventory
Start with the deployed Pods and their controllers. Record the cluster, namespace, workload owner, service-account name and image digest. Compare the live Pod with its Deployment or Job template: the template describes future Pods, while the running object tells you which identity a current instance uses.
Kubernetes assigns the namespace’s default service account when a Pod does not specify one. That assignment is an identity choice, not evidence that the application needs Kubernetes API access. Ask the checkout owner which operations actually require a cluster credential, and ask the worker owner for the resources and verbs behind its reconciliation task.
Create a small review record for each workload:
| Field | Checkout API | Reconciliation worker |
|---|---|---|
| Intended identity | Dedicated checkout account | Dedicated worker account |
| Kubernetes API use | None identified; confirm with owner | Read an explicitly named resource |
| Business validation | Checkout request completes | Reconciliation completes |
| Security validation | Unneeded API credential absent | Required read allowed; unrelated access denied |
These are proposed outcomes. Keep unknowns explicit until the application owner and technical checks resolve them. Inventory collection should record references and configuration rather than token values or Secret contents.
Kubernetes service accounts expose credentials through several paths
Inspect service-account settings, Pod settings and mounted volumes together. Kubernetes supports opting out of automatic API credential mounting with automountServiceAccountToken: false. When both the service account and Pod specify this field, the Pod’s value takes precedence. A review of the account object alone can therefore miss the workload’s actual configuration.
For checkout, place the intended setting in the controller’s Pod template and verify replacement Pods after rollout. Also inspect explicit projected service-account tokens, Secret volumes and credentials supplied by another integration. Disabling automatic mounting does not prove that every credential source has disappeared.
For a workload that needs an API token, review how the credential is obtained, its intended audience and its lifetime. Current Kubernetes supports projected, rotating service-account tokens; manually maintained long-lived token Secrets deserve separate attention. Do not create a permanent credential merely to make a failing test pass.
Keep cloud identity separate in the review record. A cloud workload-identity integration may introduce another trust relationship. Establish what the provider accepts and which cloud permissions result before claiming that a Kubernetes configuration change also removed cloud access.
Effective access requires more than reading one Role
Trace the bindings that apply to the identity, including relevant service-account groups, and resolve the Roles or ClusterRoles they reference. RBAC permissions are additive: a narrower Role does not cancel a broader grant supplied by another binding. A RoleBinding can reference a ClusterRole while granting its permissions within the binding’s namespace.
For the worker, write down the intended resource, API group, verb and namespace before editing policy. Compare that requirement with the complete access picture. Investigate wildcard permissions, access to Secrets, workload creation and identity-management operations as separate review items; their practical consequences depend on the surrounding configuration.
Assign each proposed removal an owner and a rollback condition. Shared accounts make this harder because the change can affect applications outside the initial review. Move towards identities that correspond to workload responsibilities, while checking scheduled jobs, maintenance tasks and recovery procedures before declaring a permission unused.
Test permission decisions and application behaviour separately
Use a permission matrix containing both required and prohibited actions. A required action returning an allowance is only half the test. Include unrelated resources and another namespace where appropriate, so an unexpectedly broad grant becomes visible.
Kubernetes provides kubectl auth can-i to query API authorisation. An authorised administrator can combine it with impersonation to investigate another identity. The reviewer must have the necessary impersonation privileges, and the tested identity and groups must match the intended subject; a reviewer permission error is not proof that the workload was denied.
Record each result with the cluster, subject, action, resource and timestamp. Distinguish an explicit denial from a timeout, unreachable API server or failed authentication. Where permitted, confirm the result using a controlled workload fixture and its actual authentication path, without exposing a bearer token in logs or screenshots.
Then run the business checks. Checkout should still process a synthetic request, and reconciliation should still perform its intended read. A permission query does not demonstrate application compatibility, admission behaviour or network reachability. Keep those observations separate so a broken connection cannot masquerade as successful access restriction.
Close the change on replacement Pods and retained evidence
Apply the reviewed template through the normal delivery process. Check that affected replicas have been replaced and that the live Pods carry the intended service account and credential mounts. A merged manifest is insufficient when an older replica still runs with its previous configuration.
Repeat the access matrix after the rollout and retain the results beside the change record. Capture the relevant policy revision and binding references, while keeping secret material out of the evidence. If a controller or admission webhook changes a Pod during creation, compare the admitted object with the submitted template.
Define when the review expires. Changes to bindings, workload templates, cloud trust or deployment ownership should trigger reassessment. Record a remaining exception with its owner, scope and review date instead of closing the whole workload as least-privileged. The Kubernetes admission and drift guide explains why configuration intent needs continued comparison with the cluster.
Key takeaways
- Map each running workload to its identity, owner and required API operations before changing permissions.
- Review automatic and explicit credential sources together, including any separate cloud identity relationship.
- Test required access, prohibited access and normal application behaviour as distinct outcomes.
- Verify replacement Pods and retain scoped evidence before closing the change.
How SecurityVault approaches this
SecurityVault’s platform brings application findings, workload context, identity relationships and ownership into a shared investigation. For this review, those connections help frame a specific question: which running service is associated with an access concern, and which team can evaluate the change? The useful output is an accountable investigation rather than an isolated list of service-account names.
Use the platform context alongside the cluster’s own evidence. Define the workload and permission scope, identify the responsible owner, and retain the observations that support remediation. A relationship in an inventory does not replace a permission test or demonstrate that a token is absent from every container. Likewise, a completed rollout still needs the agreed business and security checks.
An evaluation can follow the fictional checkout example: establish the affected workload, review its identity context, coordinate a scoped change and compare the resulting evidence with the closure criteria. Keep unknown coverage visible throughout. Discuss your environment to establish which sources and workflows should be included in that evaluation.