Kubernetes as a service shifts control-plane risk to IAM governance

At a glance

What this is: Kubernetes as a service gives teams managed control-plane operations, but the key finding is that workload identity and configuration risk still sit with the customer.

Why it matters: IAM, NHI, and platform teams need to treat managed Kubernetes as shared responsibility, because the provider patches the control plane while the organisation still owns access design, service accounts, and workload exposure.

👉 Read Orca Security's guide to Kubernetes as a service, advantages, and tradeoffs

Context

Kubernetes as a service is a managed operating model for Kubernetes where the cloud provider runs the control plane and customers deploy workloads on top. The primary governance question is not whether the cluster exists, but which identity and access controls remain your responsibility once the control plane is no longer self-managed.

That split matters for NHI and IAM programmes because service accounts, workload identity, and RBAC still determine who and what can reach sensitive resources. Managed Kubernetes changes the operating burden, but it does not remove the need to govern privilege, exposure, and configuration drift across clusters.

Key questions

Q: How should security teams govern Kubernetes service accounts in managed clusters?

A: Security teams should govern Kubernetes service accounts as non-human identities with explicit owners, scopes, and review cadences. In managed clusters, the provider does not reduce the need for least privilege. The practical test is whether each service account has a business purpose, a narrow permission set, and a documented reason to exist.

Q: What breaks when teams assume KaaS means the provider secures everything?

A: 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.

Q: How do organisations know if Kubernetes access control is actually working?

A: Look for evidence that service accounts are tightly scoped, cluster roles are reviewed, and network policies limit lateral movement between namespaces. If access remains broad, static, or undocumented, the control is present in name only. Effective governance produces fewer privileged identities, not just a compliant cluster configuration.

Q: Who is accountable for security when a managed Kubernetes cluster is compromised?

A: Accountability is shared, but it is not symmetrical. The vendor is accountable for the control plane it operates, while the customer remains accountable for the identities, configurations, and exposed workloads it deploys. For governance and audit purposes, the organisation must be able to show where each control owner sits.

Technical breakdown

Managed control plane versus customer-controlled workload identity

In KaaS, the vendor operates the API server, scheduler, controller manager, and etcd or a managed equivalent, while the customer controls namespaces, deployments, services, RBAC, and network policy. This creates a hard boundary between provider-managed control-plane security and customer-managed identity and workload configuration. The architecture is attractive because it removes patching and availability work, but it also means the security model is split across two administrative domains. If teams blur that boundary, they miss where actual access decisions are made and where compromise paths still exist.

Practical implication: map every Kubernetes identity control to either provider responsibility or customer responsibility before relying on the managed service.

RBAC and service accounts remain the real access layer

KaaS does not govern least privilege for you. Kubernetes RBAC, service accounts, pod security settings, and cloud IAM bindings such as IAM roles for service accounts or workload identity determine which workloads can act, read secrets, or reach APIs. That is why managed Kubernetes can be hardened on the provider side and still be insecure in practice. The control plane may be patched and stable, but an over-permissive service account still becomes a valid identity path into data and infrastructure. The risk is identity sprawl, not just cluster sprawl.

Practical implication: review Kubernetes RBAC and workload identities as first-class NHI assets, not as application plumbing.

Vendor lock-in in KaaS is mostly operational and identity-specific

Kubernetes APIs are portable, but the surrounding ecosystem often is not. Provider-specific authentication, networking, serverless options, and add-ons create dependency on one cloud's operational model. That matters because identity and access patterns become coupled to cloud-native conventions, making later migration more expensive than teams expect. The issue is not pod portability alone, but whether your security posture depends on assumptions that only one provider's integration model satisfies. In governance terms, lock-in appears first in identity integration and only later in workload YAML.

Practical implication: minimise provider-specific identity integrations where possible and document which access controls are portable across clouds.

Breaches seen in the wild

• Azure Key Vault privilege escalation exposure — Azure Key Vault Contributor role misconfiguration enabled privilege escalation.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

KaaS reduces operational burden, but it does not collapse the identity governance burden. The provider takes over the control plane, yet the customer still owns RBAC, service accounts, workload identity, and network policy. That division means most real exposure shifts from infrastructure maintenance to access design and configuration discipline. Practitioners should treat managed Kubernetes as a governance reallocation, not a security offload.

Managed Kubernetes is a workload identity problem as much as a platform problem. The article makes clear that control-plane patching is not the same thing as access control. Workloads still authenticate, receive permissions, and reach data through identities that must be governed like any other NHI estate. Teams that focus only on cluster uptime miss the more durable risk surface: over-permissioned service accounts and exposed services.

Vendor dependence in KaaS creates a patch-timing trust model that organisations must consciously accept. Teams cannot emergency-patch the control plane themselves, so the provider's update cadence becomes part of the security boundary. That is not a defect in every environment, but it is a governance assumption that must be explicit for regulated and high-sensitivity workloads. Practitioners should align the service model with their tolerance for delegated patch control.

Vendor lock-in in managed Kubernetes starts with identity integration, not with containers. Provider-specific IAM bindings, serverless options, and network controls often shape how teams build their access patterns long before migration becomes a concern. The longer those choices remain undocumented, the harder it becomes to re-platform without redesigning the security model. Practitioners should classify provider-specific access dependencies early and keep them visible in architecture reviews.

From our research:

• 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
• That same research found that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, with 38% reporting no or low visibility and 47% reporting only partial visibility.
• For a broader lifecycle lens, see NHI Lifecycle Management Guide, which helps teams govern provisioning, rotation, and offboarding across non-human identities.

What this signals

Managed Kubernetes will keep pulling identity decisions upward into platform governance. As teams remove control-plane operations from their backlog, the remaining risk concentrates in service accounts, IAM bindings, and workload policy. The programmes that adapt fastest will be the ones that inventory Kubernetes identities as part of the wider NHI estate rather than treating them as cluster-specific exceptions.

KaaS also sharpens the case for portable identity governance. Provider-specific integrations can simplify operations, but they make future migrations and security reviews harder when the access model is embedded in one cloud's conventions. Teams should keep one abstraction layer for identity ownership and another for provider-specific implementation, or auditability will degrade over time.

1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months. That investment pattern shows the market is moving toward explicit machine identity governance, which is exactly where managed Kubernetes belongs. Practitioners should align KaaS decisions with NHI tooling, not just with platform engineering priorities.

For practitioners

• Map control-plane and workload responsibilities Document which controls sit with the provider and which remain with your team, including RBAC, service accounts, pod security, and network policy. Use that split as the basis for security ownership and audit evidence.
• Treat Kubernetes identities as governed NHIs Inventory service accounts, cloud IAM bindings, and workload identity relationships across every cluster. Review them on the same cadence you use for other non-human identities so privilege does not accumulate invisibly.
• Validate provider patch timing against your exposure tolerance Compare the provider's control-plane update model with your internal CVE response requirements, especially for regulated workloads. If you cannot tolerate delayed provider patching, define compensating controls before go-live.
• Reduce provider-specific identity coupling Prefer standard Kubernetes resources and portable manifest patterns where possible. Keep a record of any provider-specific authentication or networking feature that would need redesign during migration.

Key takeaways

• KaaS moves Kubernetes operations to the provider, but access governance, workload identity, and configuration risk remain with the customer.
• The most important security control in managed Kubernetes is still least privilege for RBAC and service accounts, not cluster uptime alone.
• Teams that adopt KaaS without portable identity governance will trade operational speed for long-term control and migration complexity.

Key terms

• Kubernetes as a service: A managed Kubernetes model where a cloud provider operates the control plane and related platform components for you. Customers still deploy workloads, configure access, and govern security. The main tradeoff is reduced operational effort in exchange for less direct control over cluster internals.
• Service Account: A non-human identity used by workloads or Kubernetes components to authenticate and act inside a cluster. In managed environments, service accounts must be governed like any other privileged identity because their permissions can expose secrets, data, and internal APIs if they are too broad.
• Workload Identity: A mechanism that binds a workload to a cloud identity so the workload can access services without static credentials. It reduces secret sprawl, but it still requires tight policy design, ownership, and review because mis-scoped identity bindings create the same exposure as any other over-permissioned account.
• Control Plane: The Kubernetes layer that schedules workloads, stores cluster state, and handles API requests. In KaaS, the provider usually manages this layer, but customers still own workload security, access configuration, and the identities that interact with the cluster.

Deepen your knowledge

KaaS governance, RBAC, and workload identity are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are standardising managed Kubernetes across cloud platforms, it is a strong fit for your programme.

This post draws on content published by Orca Security: Kubernetes as a service, advantages, disadvantages, and major providers. Read the original.