Notifications
Clear all
Topic starter
09/06/2026 11:14 pm
TL;DR: Kubernetes as a service moves the Kubernetes control plane to the provider while leaving RBAC, network policies, pod security, and workload identity under customer control, according to Orca Security. That division makes governance, not just provisioning speed, the deciding factor in whether managed Kubernetes reduces risk or simply relocates it.
NHIMG editorial — based on content published by Orca Security: Kubernetes as a service, advantages, disadvantages, and major providers
Questions worth separating out
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.
Q: What breaks when teams assume KaaS means the provider secures everything?
A: What breaks is the shared responsibility model.
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.
Practitioner guidance
- 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.
- Treat Kubernetes identities as governed NHIs Inventory service accounts, cloud IAM bindings, and workload identity relationships across every cluster.
- 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.
What's in the full article
Orca Security's full article covers the operational detail this post intentionally leaves for the source:
- Provider-by-provider comparison of EKS, GKE, AKS, Tanzu, and OpenShift operating models
- Details on serverless options, node lifecycle handling, and pricing structures
- The article's practical notes on patching, version support, and vendor-specific identity integrations
- Additional Kubernetes security references and glossary context for implementation teams
👉 Read Orca Security's guide to Kubernetes as a service, advantages, and tradeoffs →
KaaS governance gap: are your controls keeping up with managed Kubernetes?
Explore further
10/06/2026 1:31 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Kubernetes as a service shifts control-plane risk to IAM governance
