Notifications
Clear all
Topic starter
10/06/2026 11:34 pm
TL;DR: Kubernetes security remains hard because clusters combine service accounts, secrets, control planes, IaC pipelines, and compliance evidence into one tightly coupled operating model, according to Orca Security. The practical issue is not visibility alone but whether identity, traceability, and remediation stay coherent as environments scale faster than manual governance.
NHIMG editorial — based on content published by Orca Security: Navigating the Complexities of Kubernetes Security
Questions worth separating out
Q: How should security teams govern Kubernetes service accounts and secrets?
A: Treat Kubernetes service accounts and secrets as governed non-human identities, not as incidental configuration.
Q: Why do Kubernetes environments create so many identity governance gaps?
A: Kubernetes creates gaps because identity, deployment, and runtime state change in different places and at different speeds.
Q: How do teams know if Kubernetes posture management is actually working?
A: KSPM is working when findings are not just collected, but triaged into clear owners and remediated from the right source.
Practitioner guidance
- Map Kubernetes service accounts to business owners Create a live inventory of service accounts, the workloads that use them, and the team responsible for each account.
- Trace every production finding back to IaC Require each high-risk cluster issue to link to the originating repository, commit, pipeline stage, and approver.
- Prioritise reachable Kubernetes risks first Score issues by external exposure, control-plane reachability, and privilege path before assigning remediation work.
What's in the full article
Orca Security's full post covers the operational detail this post intentionally leaves for the source:
- The session recording and speaker discussion on Kubernetes security priorities across cluster, pipeline, and compliance layers
- More detail on KSPM usage for visualising cluster posture across environments and control-plane configurations
- Examples of how AI-driven insights are used to prioritise reachable vulnerabilities and remediation work
- The article's own framing of integrated CNAPP data for compliance monitoring and reporting
👉 Read Orca Security's analysis of Kubernetes security and KSPM →
Kubernetes security: where identity, lifecycle, and traceability fail?
Explore further
12/06/2026 5:48 am
Kubernetes security is really NHI governance with a platform wrapper. Service accounts and secrets are the persistent identity layer that determines how workloads act, not just how they start. Once those credentials become scattered across CI/CD, control planes, and runtime environments, the security problem is lifecycle governance as much as posture management. Practitioners should treat Kubernetes identity as a governed asset family, not a set of isolated cluster settings.
A few things that frame the scale:
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to the 2024 ESG Report: Managing Non-Human Identities.
- Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, which shows how quickly identity weaknesses recur once they are inside the environment.
A question worth separating out:
Q: What should organisations do when Kubernetes compliance data is fragmented?
A: They should centralise compliance evidence around the cluster identities, configurations, and pipeline events that produced the state being audited. Fragmented reporting usually hides the real control failure, which is why compliance should be evidence-driven rather than assembled manually after the fact.
👉 Read our full editorial: Kubernetes security still breaks at identity, lifecycle, and traceability
