More identities can read your Secrets than the ones with a get permission on them. List and watch also reveal values, creating a pod that mounts a Secret exposes it, and wildcard rules cover Secrets silently. This five step audit finds them using kubectl and your audit log.
Why the obvious check misses people
The Kubernetes docs on Secrets good practices say that list implicitly exposes Secret contents, and that anyone who can create a pod using a Secret can read its value even without direct read permission. The RBAC guidance adds that creating workloads in a namespace implicitly grants access to its Secrets, ConfigMaps and volumes, and the API access of any service account there.
So you need to look for four kinds of access: direct verbs, wildcards, pod creation, and service account reach.
Step 1: ask the API directly
kubectl can answer for a named identity.
kubectl auth can-i list secrets --namespace prod --as jane@example.com
kubectl auth can-i get secrets --namespace prod --as system:serviceaccount:prod:ci
kubectl auth can-i create pods --namespace prod --as jane@example.com
Run it for each important namespace and for the identities you care about, including service accounts. The can-i command takes impersonation, which itself needs permission to use.
Step 2: search roles for wildcards
Export Roles and ClusterRoles and look for a star in the resources or verbs fields. The docs warn wildcards cover future object types as well as current ones.
Step 3: find who can create pods or workloads
List subjects bound to roles that allow creating pods, deployments, jobs or cronjobs. Treat them as Secret readers for that namespace. Enforcing a Baseline or Restricted Pod Security level limits what those pods can do, though not what they can mount.
Step 4: review service accounts
Find service accounts bound to roles with Secret access. Then find pods that use them. Pods that do not need the API should not mount a token at all, see Kubernetes service account tokens explained.
Step 5: check the log for actual reads
With an audit policy that logs Secrets at Metadata level, look for one user reading many Secrets, which the docs name as a suspicious pattern, and for reads by identities that have no business with them. See a starter audit policy.
What to change afterwards
- Restrict watch and list to the most privileged, system-level components. Grant get only when needed.
- Limit human access, including read-only.
- Allow only cluster administrators to reach etcd.
- Separate namespaces to isolate mounted Secrets.
- Consider an external store with the Secrets Store CSI Driver, which the docs describe.
Safeguard's compliance and evidence automation can help record access reviews as evidence, if you already map them to a control.
Quick check
Does kubectl auth can-i show wildcard access?
Yes, it evaluates the effective permission, so a wildcard rule makes the answer yes.
How often should I run this?
Quarterly, plus after team changes or new platform tools.
Sources
Last reviewed: 19 October 2026.
