Secret access: audit workload creation as an indirect read permission

Last updated: 1 Oct 20266 min read

tutorial

Secret RBAC is not limited to direct get, list, and watch requests. A subject that can create a Pod or a controller that creates Pods in a namespace can often mount a Secret there and arrange for a container to reveal its contents. The namespace and workload-admission boundary therefore matters as much as the Secret-reader role. List and watch permissions can also reveal all Secret data returned by those API operations.

Operational decision

A build automation identity may deploy a claims service but must not gain access to the settlement signing key. Place the signer in a separately administered namespace and give the build identity no workload-creation privilege there. Review permission to create Pods, Deployments, Jobs, and other Pod-producing resources in each namespace, plus permission to alter the service account or Pod template of a trusted workload. In an isolated test cluster, impersonate the identity and attempt to create a Pod that mounts the protected Secret; the admission or authorization check must deny it before scheduling. The command below tests one direct workload permission, but an audit must enumerate controller resources and inherited roles as well. Use audit logs to detect unusual bulk Secret reads and workload creation near sensitive mounts. A Secret volume mounted only into a signer sidecar can narrow exposure inside a trusted Pod, but it does not repair a namespace that accepts arbitrary attacker-controlled Pods.

kubectl auth can-i create pods -n settlement --as=system:serviceaccount:ci:claims-deployer
kubectl auth can-i create deployments.apps -n settlement --as=system:serviceaccount:ci:claims-deployer
kubectl auth can-i list secrets -n settlement --as=system:serviceaccount:ci:claims-deployer

Cost and verification

Separate namespaces and admission checks add deployment administration and may require a controlled promotion service. They reduce the blast radius of a compromised CI identity. Measure identities with workload-create rights in sensitive namespaces, rejected unauthorized Pod attempts, and broad Secret list or watch grants. A can-i denial is useful evidence for that specific verb and resource; it does not prove that a different controller, impersonation path, or privileged service account cannot reach the same data.

Common Mistakes

Do not call a role safe merely because it lacks direct Secret get.
Do not overlook Deployments, Jobs, and other resources that create Pods.
Do not mount a signing key into a container that does not need it.

Connected lessons

Practice and check

devops

operations