How would you audit which pods across a cluster consume a specific Secret, before rotating it, to know what needs restarting?

There's no single built-in kubectl command that lists a Secret's consumers directly — you need to search across pod specs for every place the Secret's name could appear as a reference: volumes (as a secret volume source), env/envFrom (secretKeyRef/secretRef), and separately, imagePullSecrets on both pods and ServiceAccounts, since that's a distinct reference path that's easy to forget.

Search pod specs (via their owning Deployments/StatefulSets/DaemonSets) for the Secret's name in spec.volumes: kubectl get deployments,statefulsets,daemonsets -A -o json | jq '.items[] | select(.spec.template.spec.volumes[]?.secret.secretName=="<secret-name>") | .metadata.name' (adjusted for whichever controller kinds are relevant) finds every workload mounting the Secret as a volume.

Search for env/envFrom references separately, since they're a different field path: .spec.template.spec.containers[].env[].valueFrom.secretKeyRef.name and .spec.template.spec.containers[].envFrom[].secretRef.name both need to be checked — a workload could reference the same Secret through either mechanism, or both, and a search that only checks one will miss the other.

Don't forget imagePullSecrets, a commonly-overlooked reference path: a Secret can also be referenced as an imagePullSecrets entry on a pod spec directly, or on the ServiceAccount the pod uses (which then applies implicitly to every pod using that ServiceAccount) — this is a genuinely different consumption pattern than config/credential injection, and searching only env/volumes will miss it entirely, potentially causing image pulls to start failing after a rotation if this path wasn't accounted for.

A pre-built tool or script is more reliable than manual kubectl inspection for anything beyond a small cluster: given the number of field paths and object kinds involved, a script that systematically walks every workload type's pod template (Deployments, StatefulSets, DaemonSets, Jobs, CronJobs) and checks all three reference patterns (volumes, env, imagePullSecrets) — or an existing open-source tool built for this kind of RBAC/reference auditing — is considerably more reliable than trying to remember and manually check every path by hand each time.

Cross-reference with the Secret's namespace, since Secrets are namespace-scoped: a Secret can only be referenced by workloads in the same namespace as the Secret itself — this narrows the search scope naturally and also means "which namespace is this Secret actually in" is worth confirming first, especially if the same Secret name exists in multiple namespaces coincidentally (which are entirely unrelated objects despite sharing a name).

• No single built-in command lists a Secret's consumers — the search has to cover volumes, env/envFrom, and imagePullSecrets as three genuinely separate reference paths.
• imagePullSecrets (on pods or ServiceAccounts) is a commonly-overlooked consumption pattern distinct from config/credential injection.
• A systematic script covering every workload kind (Deployments, StatefulSets, DaemonSets, Jobs, CronJobs) is more reliable than ad hoc manual inspection for anything beyond a trivially small cluster.
• Secrets are namespace-scoped — only workloads in the same namespace can reference a given Secret, which narrows and clarifies the search.

• Kubernetes: Secrets
• Kubernetes: Pull an Image from a Private Registry