What breaks is the shared responsibility model. The provider secures the control plane, but customers still own RBAC, workload identity, network exposure, and pod-level security. If teams assume the platform covers those layers, they leave privilege and exposure unmanaged even when the cluster itself is fully supported.
Why This Matters for Security Teams
When teams assume KaaS means the provider secures everything, they misread the shared responsibility model and create blind spots in the layers that matter most to attackers. The provider may harden the control plane, but customers still own RBAC, workload identity, network exposure, secrets handling, and pod-level security. That gap is where privilege accumulates and misconfigurations survive. NHI Mgmt Group notes that 97% of NHIs carry excessive privileges, which is exactly the kind of issue that slips through when ownership is unclear.
This is not just a cloud operations problem. It is an identity and exposure problem that shows up in Kubernetes, CI/CD, and service-to-service traffic at the same time. Guidance from the NIST Cybersecurity Framework 2.0 reinforces that governance and asset ownership must be explicit, not assumed. The same pattern appears in NHI governance research from NHI Mgmt Group, especially where secrets and service accounts are left outside formal oversight.
In practice, many security teams encounter overprivileged workloads only after lateral movement or secret exposure has already occurred, rather than through intentional review.
How It Works in Practice
A secure KaaS operating model starts by separating provider responsibilities from customer responsibilities. The provider typically secures the managed infrastructure, control plane availability, and platform patching. The customer still owns the identities that run inside the cluster, the permissions those identities receive, and the paths by which workloads reach internal and external services. That means RBAC, Kubernetes service accounts, network policies, admission controls, secrets distribution, and pod security standards remain customer obligations.
For NHI-heavy environments, the practical question is not whether the cluster is supported, but whether each workload has a narrowly scoped identity with revocation, rotation, and auditability. That is why teams should align workload identity with least privilege and avoid static credentials where possible. Current guidance increasingly favors workload-native identity, short-lived tokens, and policy enforcement at request time rather than relying on broad cluster-level trust. The Ultimate Guide to NHIs highlights how often organisations miss these basics, and the scale of the problem is easy to see when secrets are stored in vulnerable places or never rotated.
Operationally, this usually means:
- Defining a clear responsibility matrix for cluster, node, namespace, workload, and secret ownership.
- Treating Kubernetes service accounts as identities, not just defaults attached to pods.
- Restricting pod-to-pod and pod-to-internet paths with network policies and egress controls.
- Using short-lived credentials and central secret management instead of embedded static keys.
- Reviewing RBAC bindings and namespace boundaries on a fixed schedule, not only during incidents.
Teams that adopt the NIST Cybersecurity Framework 2.0 mindset tend to catch ownership gaps earlier because governance, protection, and monitoring are explicitly mapped to each layer. These controls tend to break down when platform teams assume namespace defaults are safe in multi-tenant clusters because lateral access then expands faster than reviews can contain it.
Common Variations and Edge Cases
Tighter customer-side control in KaaS often increases operational overhead, requiring organisations to balance convenience against the risk of unmanaged privilege. That tradeoff becomes sharper in fast-moving environments where application teams spin up namespaces quickly, or where platform teams provide opinionated templates that are never reviewed after deployment.
There is no universal standard for exactly where provider responsibility ends in every KaaS model, so contracts and control mappings matter. Best practice is evolving, but customers should never assume the provider covers workload identity, secret rotation, or pod security simply because the cluster is managed. In regulated environments, that assumption can also create audit gaps because accountability for RBAC drift and exposed credentials remains with the customer.
Edge cases include operators that offer deeper guardrails, such as managed policy engines or integrated identity tooling. Even then, those features only help if they are enabled, scoped correctly, and monitored continuously. The lesson from incidents such as the JetBrains GitHub plugin token exposure is that identity exposure rarely stays contained to one layer. In KaaS, the same pattern emerges when teams trust the platform to secure secrets, permissions, and runtime behavior by default.
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 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Addresses excessive privilege and unmanaged non-human access in managed clusters. |
| CSA MAESTRO | Covers shared responsibility and governance for agentic and workload identities. | |
| NIST AI RMF | Supports governance and accountability for automated workload decisions and access. |
Assign accountability for runtime access decisions and monitor identity behavior continuously.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
