Review Kubernetes workload-creation permission as access to namespace resources

An identity can gain useful access through a Pod even without a direct Secret-read role.

Resilient network core with engineered blue and gold data paths.
DSE visual intelligenceNetworks & infrastructureGuide · 2 min read
Executive summary

What you need to know

An identity can gain useful access through a Pod even without a direct Secret-read role.

Potentially affected

Review indirect namespace access from workload creation alongside Secret get, list and watch permissions.

DSE recommendation

DSE recommends mapping what an identity can cause the cluster to run, not merely what it can retrieve directly.

An identity can gain useful access through a Pod even without a direct Secret-read role.

Source facts

Kubernetes RBAC guidance explains that permission to create workloads in a namespace can implicitly expose resources such as Secrets, ConfigMaps, and ServiceAccounts available to those workloads. It also warns that list and watch permissions on Secrets can reveal their contents. A permission review limited to the get verb therefore misses important access paths.

Source: Kubernetes documentation — Role Based Access Control Good Practices.

Applicability

Review indirect namespace access from workload creation alongside Secret get, list and watch permissions.

DSE recommendation

DSE recommends mapping what an identity can cause the cluster to run, not merely what it can retrieve directly. Review workload creation, identity selection, mounts, and privileged execution possibilities together with Secret permissions. Separate application deployment authority from broad namespace administration where the operating model permits it. Record any compensating admission controls and verify they are actually enforced. Avoid granting a deployment tool an entire namespace’s trust simply because its normal workflow only updates one application.

Verification

In an isolated namespace containing disposable credentials, evaluate the proposed role’s direct and indirect access. Test an approved workload creation and a deliberately disallowed resource reference. Confirm that audit records identify the initiating identity and that the documented restriction prevents the unintended path. Have the deployment owner demonstrate the intended application’s permitted references, then record the exact admission rule or role boundary responsible for rejecting the unwanted reference. Keep disposable Secret values out of the retained audit examples.

Official reference

Kubernetes documentation — Role Based Access Control Good Practices. Reviewed October 20, 2026.

Primary reference

Review the official source

Kubernetes documentation — Role Based Access Control Good Practices · Verified October 20, 2026

Open official reference ↗
Plan the next step

Need help applying this guidance safely?

DSE can help confirm applicability, protect service continuity, and validate the result across physical security and IT systems.

Talk with DSE