# 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.

- Canonical URL: https://update.dsesecurity.com/updates/review-kubernetes-workload-creation-permission-as-access-to-namespace-resources/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-10-20T18:14:58+00:00
- Modified: 2026-10-20T18:34:32+00:00
- Last reviewed by DSE: 2026-10-20
- Resource type: Guide
- DSE priority: Information
- Topics: IT, Networks & Infrastructure
- Reading time: 2 minutes

## 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.

## Article

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](https://kubernetes.io/docs/concepts/security/rbac-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](https://kubernetes.io/docs/concepts/security/rbac-good-practices/). Reviewed October 20, 2026.

## Primary reference

- Name: Kubernetes documentation — Role Based Access Control Good Practices
- Authority: kubernetes.io
- URL: https://kubernetes.io/docs/concepts/security/rbac-good-practices/
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Review Kubernetes workload-creation permission as access to namespace resources,” DSE Security, https://update.dsesecurity.com/updates/review-kubernetes-workload-creation-permission-as-access-to-namespace-resources/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.