Use a brokered access model that authenticates the user, authorises each request, and records the session before the command reaches the Kubernetes API server. That approach reduces standing exposure and creates a reviewable audit trail. The key is to make the intermediary the enforcement point, not a convenience layer.
Why This Matters for Security Teams
Direct cluster credentials turn every permitted user into a potential cluster-admin path, even when they only need limited operational access. For Kubernetes, that is especially dangerous because tokens, kubeconfigs, and copied client certificates are often reusable far beyond the original task. Current guidance from the OWASP Non-Human Identity Top 10 and the NIST Cybersecurity Framework 2.0 both point toward tighter identity proofing, least privilege, and continuous monitoring, but Kubernetes access still often gets handled like a convenience problem instead of an identity problem. That is where standing privilege, weak auditability, and credential sharing creep in.
NHIMG research on secret exposure shows why this model is brittle: Guide to the Secret Sprawl Challenge and Ultimate Guide to NHIs — Static vs Dynamic Secrets both reinforce the operational risk of long-lived credentials that outlive the intent behind them. In practice, many security teams encounter misuse only after a copied kubeconfig or over-broad token has already been reused outside the original approval path, rather than through intentional design.
How It Works in Practice
A brokered model moves the control point in front of the Kubernetes API server. The user authenticates to an intermediary, the intermediary evaluates the request, and only then does it mint or proxy a short-lived path into the cluster. That intermediary can enforce RBAC, but the stronger pattern is to combine RBAC with request-time policy, session recording, and JIT credential issuance so the user never receives a reusable cluster secret. NIST’s identity guidance supports this direction, and the NIST SP 800-63 Digital Identity Guidelines are useful for thinking about authentication assurance before access is granted.
For implementation, security teams usually need four pieces:
- Strong user authentication to the broker, not to the cluster directly.
- Ephemeral session credentials or impersonation that expire quickly and are revoked automatically.
- Policy checks tied to request context, such as namespace, workload, time, and command type.
- Complete logging of the approved session before the request reaches the API server.
That design is aligned with the core NHI lessons in 52 NHI Breaches Analysis: long-lived access and poor visibility are what make identity abuse durable. Security teams should treat the broker as an enforcement layer, not a jump host. These controls tend to break down when administrators bypass the broker for emergency troubleshooting because the exception path quietly becomes the real access path.
Common Variations and Edge Cases
Tighter brokered access often increases operational overhead, so organisations have to balance developer speed against reduced standing privilege. In smaller environments, a pure proxy may be enough; in regulated or larger clusters, current best practice is evolving toward policy-as-code, JIT access, and stronger workload identity binding rather than static user tokens. The exact mix is not universal yet, especially where teams still rely on legacy kubectl workflows or shared bastion access.
Some edge cases need special handling. Break-glass access should exist, but it must be separately approved, time-boxed, and heavily monitored. Automation and CI/CD should not use the same access path as human operators; they need workload identity, not copied human credentials. That distinction matters because an autonomous workload behaves differently from a person at a terminal, and its identity lifecycle should reflect that. For broader context on identity sprawl and secret lifecycle risk, see Top 10 NHI Issues and the Ultimate Guide to NHIs.
For governance, this fits best with the identity and zero-trust direction set by OWASP Non-Human Identity Top 10 and NIST Cybersecurity Framework 2.0. The practical rule is simple: if a user can obtain reusable cluster credentials, the broker is not yet doing its job.
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 CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Directly addresses unmanaged and long-lived NHI credentials in cluster access. |
| NIST CSF 2.0 | PR.AC-4 | Maps to controlled access enforcement and least privilege for Kubernetes sessions. |
| NIST SP 800-63 | AAL2 | Supports stronger authentication before granting access to the brokered path. |
Require authenticated users to reach the broker with assurance fit for privileged actions.
