A model where requests to a Kubernetes cluster pass through an identity-aware intermediary instead of using direct cluster credentials. The broker authenticates, authorises, and records the session, which reduces standing exposure and creates a reviewable control point for privileged activity.
Expanded Definition
Brokered Kubernetes Access is an identity-aware control pattern in which a request reaches a Kubernetes cluster only after passing through an intermediary that authenticates the requester, authorises the action, and records the session. It reduces the need for direct cluster credentials and supports Zero Standing Privilege by making access temporary, attributable, and reviewable.
In practice, the broker may issue short-lived access, map the requester to a narrow role, or mediate an interactive session for privileged operations. This is closely related to modern NHI governance described in the Ultimate Guide to NHIs, and it aligns with the intent of the OWASP Non-Human Identity Top 10, even though implementations vary across vendors and cluster architectures. No single standard governs brokered Kubernetes access yet, so teams often adapt PAM, RBAC, or workload identity tooling to achieve the same control objective.
The most common misapplication is treating a broker as a thin login proxy, which occurs when users still retain persistent kubeconfig files, long-lived tokens, or direct API paths that bypass the intermediary.
Examples and Use Cases
Implementing Brokered Kubernetes Access rigorously often introduces latency and operational dependency on the broker, requiring organisations to weigh stronger accountability against reduced admin convenience and added failure modes.
- A platform engineer requests cluster-admin access through a broker for a production incident, receives a time-bound session, and the activity is logged for post-incident review.
- A CI/CD pipeline is constrained to invoke the Kubernetes API only through a broker that exchanges workload identity for a scoped token, limiting blast radius if the pipeline is compromised.
- A third-party SRE connects during a maintenance window through an identity-aware gateway rather than using shared credentials, supporting the third-party exposure concerns highlighted in the Ultimate Guide to NHIs — Key Challenges and Risks.
- A security team requires all privileged kubectl actions to be brokered and compared against the cluster audit trail, which improves evidence quality for investigations.
- A container platform uses brokered access for emergency break-glass operations so that standing admin roles remain disabled until a specific approval is granted.
These patterns echo the access-minimisation direction in identity guidance and the control expectations described in the OWASP Non-Human Identity Top 10, especially where direct secrets would otherwise be copied into scripts, laptops, or automation jobs.
Why It Matters in NHI Security
Brokered Kubernetes Access matters because Kubernetes environments are often controlled by non-human identities that outnumber human identities by 25x to 50x in modern enterprises, and only 5.7% of organisations report full visibility into their service accounts, according to the Ultimate Guide to NHIs. Without a broker, teams tend to accumulate static kubeconfigs, token sprawl, and unreviewed admin paths that defeat least privilege.
The security value is not just authentication. It is also the creation of an attributable decision point where authorisation, approvals, and session recording can be correlated with cluster events and secrets usage. That makes the model relevant to zero trust planning, especially when privileged access must be justified rather than assumed. The same risk pattern shows up in breach analysis, where 52 NHI Breaches Analysis illustrates how machine identities and exposed credentials often become the path of least resistance.
Organisations typically encounter the need for brokered access only after a cluster compromise, an overbroad service account, or a leaked token forces them to retrofit control and auditability into operations.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Brokered access reduces standing privileges and direct secret exposure in Kubernetes. |
| NIST Zero Trust (SP 800-207) | PE-3 | Zero Trust requires continuous verification before cluster access is granted. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access control applies directly to brokered cluster sessions. |
Mediate Kubernetes access through explicit trust checks, not network location or default admin paths.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
