How do you restrict a Pod's access to a Secret?

WHAT THIS TESTS Whether you know that authorization for Secrets is identity-based through RBAC and ServiceAccounts, and that there are two distinct access paths: API reads and in-spec mounting.

A GOOD ANSWER COVERS A Pod authenticates to the API server as its ServiceAccount. To restrict API access to Secrets, assign the Pod a dedicated ServiceAccount instead of default, then create a Role that grants get and list only on the Secrets it legitimately needs, using resourceNames to enumerate allowed Secret names. Bind that Role with a RoleBinding. Any Secret not listed is denied at the API layer. The second path is mounting: if a Secret is referenced in the Pod's volumes or envFrom, the kubelet supplies it regardless of RBAC, because the Pod author chose it. So you control this path by controlling who can edit the Pod spec and by simply not mounting Secrets the Pod should not see. Combine least-privilege ServiceAccounts with restricted spec authorship.

COMMON WRONG ANSWERS Believing RBAC blocks a Secret already mounted into the Pod. Trying to set permissions on the Pod object rather than its ServiceAccount. Putting every Pod on the default ServiceAccount and expecting per-Pod isolation. Confusing NetworkPolicy with Secret access.

LIKELY FOLLOW-UPS How does resourceNames narrow a Role? Why does mounting bypass RBAC checks? How do admission controllers or policy engines like Kyverno enforce which Secrets a spec may mount?

ONE CONCRETE EXAMPLE Create ServiceAccount app-sa, a Role with rules getting verbs get on resources secrets with resourceNames app-config only, bound via RoleBinding to app-sa. A Pod running as app-sa that calls the API for another Secret named db-creds receives Forbidden, while the default ServiceAccount Pods are unaffected.