Context
A ServiceAccount names a workload identity. Its token proves that identity to an accepting service, while RBAC decides which Kubernetes operations the identity may perform. A token can be valid but unauthorized, or unsuitable for the receiver even when the ServiceAccount has the right role. Treat authentication and authorization as separate tests.
Before starting, identify the Pod, namespace, ServiceAccount, target API, and exact operation that fails. You need permission to inspect workload specifications and relevant role bindings. Impersonation checks require their own permission; do not assume every operator may run them. Never copy a bearer token into logs or a shared diagnostic document.
1. Identify the live workload identity
kubectl -n shop get pod catalog-abc -o yaml
kubectl -n shop get serviceaccount catalog -o yaml
kubectl -n shop get rolebindings -o yaml
Check serviceAccountName, automountServiceAccountToken, and projected volumes. A Deployment template change does not establish which ServiceAccount an existing Pod uses. Workloads that do not call an API may intentionally disable automatic token mounting. Do not add credentials merely because a conventional token path is absent.
2. Check the credential contract
Modern projected ServiceAccount tokens are time-bound and rotated by the kubelet. An application should consume the current token file through a rotation-aware client rather than read it once and retain the original string indefinitely. For a non-Kubernetes receiver, confirm that the configured token audience matches the audience the receiver accepts.
For an explicitly illustrative example, a helper service accepts tokens with audience reports-api, but a caller sends its ordinary Kubernetes API token. Granting a broader RoleBinding cannot fix this audience mismatch. The approved design needs a correctly scoped projected token and receiver-side validation, without distributing a permanent Secret token as a workaround.
3. Test the exact authorization question
When permitted, ask Kubernetes about the precise verb, resource, and namespace:
kubectl auth can-i get configmaps --as=system:serviceaccount:shop:catalog -n shop
kubectl auth can-i list secrets --as=system:serviceaccount:shop:catalog -n shop
The second check is an illustrative negative control, not a suggestion that the application should receive Secret-listing permission. Compare the actual request's API group, subresource, and resource name with its Role or ClusterRole. A namespaced RoleBinding and a cluster-wide binding have different reach.
Match response evidence to the next step
| Evidence | Likely boundary | Next inspection |
|---|---|---|
| 401 with an expired or rejected token | Authentication | Rotation-aware loading and audience |
| 403 identifying the expected ServiceAccount | Authorization | Exact RBAC rule and binding scope |
| Request uses the default ServiceAccount | Workload assignment | Live Pod serviceAccountName |
| Access works at startup then fails later | Credential refresh | Client token-file reload behavior |
A successful can-i result does not prove that the application presents the same credential to the same endpoint. Conversely, it can isolate a missing rule without exposing the token. Keep transport failures and certificate validation errors outside this particular authentication-versus-RBAC diagnosis.
Correct narrowly and verify rotation
Change the smallest responsible identity assignment, token projection, client behavior, or RBAC rule through normal review. Verify the allowed read operation and a deliberately disallowed operation. In a controlled test, observe behavior across token rotation rather than stopping at the first successful request.
Maintain an identity register linking workload, audience, permitted operations, and owner. Review bindings when applications change API calls. Monitor authentication failures separately from authorization denials, and keep sanitized receiver logs sufficient to identify identity and operation without storing the credential.
Explore Clouvenix containers kubernetes for implementation and operational handover.
Technical reference
Service Accounts, bound-token management and RBAC authorization.