Permission to create pods or workload resources in a namespace is much more than permission to run containers. According to the Kubernetes docs, it implicitly grants access to Secrets, ConfigMaps and mountable volumes there, lets a pod run as any service account in the namespace, and with privileged pods can reach the node.
What a pod can reach
The RBAC good practices page lists the consequences:
- Secrets, ConfigMaps and PersistentVolumes that can be mounted in that namespace.
- Any service account in the namespace, since a pod can run as it and inherit its API access.
- Node access, if privileged pods are allowed.
The Secrets guidance says it simply: a user who can create a pod that uses a Secret can also see the value of that Secret.
Persistent volumes add a path
Creating arbitrary PersistentVolumes is a separate risk. It allows hostPath volumes, which give pods access to the node's host filesystem. Treat PersistentVolume creation as a cluster level grant even if it looks like storage admin work.
What the docs recommend
If you do not fully trust a principal to create isolated pods, enforce the Baseline or Restricted Pod Security Standard using Pod Security admission or a third party mechanism. The docs also say to treat boundaries within a namespace as weak, and to use namespaces to separate different trust levels.
Baseline blocks, among other things, host namespaces, privileged containers and hostPath volumes. Restricted goes further. See our post on Pod Security Standards baseline vs restricted.
A practical review
- List who can create pods, deployments, jobs and cronjobs in each namespace. Do not forget CI service accounts.
- For each namespace, list the Secrets and service accounts reachable by those principals.
- Check the Pod Security labels on the namespace and who can change them.
- Move powerful service accounts and sensitive Secrets into their own namespaces, away from broad workload creators.
- Keep powerful pods away from untrusted ones. The docs suggest taints and tolerations, node affinity or pod anti-affinity.
A rule of thumb
Think of pod creation as roughly equal to "can read everything the namespace can read". If that sounds too strong for a developer role, either shrink the role or shrink what lives in the namespace.
Where Safeguard fits
Safeguard cannot restrict pod creation inside your cluster. It can run policies and gates on the manifests in pull requests, and a policy can flag privileged settings and hostPath volumes before merge.
Example of a narrower design
Put the application and its Secrets in one namespace, and give the deploy pipeline rights only there. Put shared, powerful service accounts in a separate namespace that the pipeline cannot touch. The pipeline can still deploy, but a compromised pipeline cannot run a pod as a powerful account that lives elsewhere. This follows the docs' advice to use namespaces to separate trust levels.
Quick check
Does a deployer role need explicit Secrets access to read Secrets?
Not necessarily. If it can create pods that mount a Secret in the namespace, it can read the value through the pod.
Sources
- Role Based Access Control Good Practices, Kubernetes docs
- Good practices for Kubernetes Secrets, Kubernetes docs
- Pod Security Standards, Kubernetes docs
Last reviewed: 19 October 2026.
