How do you restrict a Pod's access to a Secret?
how Pods get Secret access via identity.
Pods read Secrets through their ServiceAccount and RBAC, scoped with resourceNames; mounted Secrets are governed by the Pod spec.
What's really being asked
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.
The full answer
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.
The mistakes people make
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.
What usually comes next
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?
A 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.
Interview question
Within one namespace, how do you stop a particular Pod from reading a Secret via the API while other Pods can?
- a.Apply a NetworkPolicy targeting the Secret
- b.Add a deny annotation to the Secret object
- c.Set the Secret to immutable
- d.Give the Pod a ServiceAccount whose Role omits that SecretCorrect
Why? this is the answer
API access to Secrets is authorized by the Pod's ServiceAccount through RBAC, so a dedicated ServiceAccount with a Role that excludes the Secret denies access. NetworkPolicy governs network traffic, and immutability prevents edits, neither controls who can read.
Just read this? Test yourself on what you have been reading.
Read the original → kubernetes.io
- #kubernetes
- #rbac
- #secrets
- #serviceaccount
- #authorization
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on kubernetes — each one lists the topics its interview covers.
See open roles