Notifications
Clear all
Topic starter
17/08/2026 4:42 pm
TL;DR: Kubernetes namespace separation is increasingly a compliance and security requirement in financial services, with Teleport arguing that static access, broad RBAC, and weak auditability make isolated namespace operations harder to sustain at scale. The real issue is that namespace controls fail when identity governance does not keep pace with workload growth, ephemeral access, and regulatory proof requirements.
NHIMG editorial — based on content published by Teleport: Kubernetes Namespace Restriction and Separation
By the numbers:
- 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.
- Only 5.7% of organisations have full visibility into their service accounts.
Questions worth separating out
Q: How should security teams govern Kubernetes namespace access in regulated environments?
A: Security teams should govern namespace access as a workload identity problem, not just a cluster policy problem.
Q: Why do Kubernetes namespaces still create risk when access is already role based?
A: Role based access still creates risk when roles are too broad, long lived, or reused across teams.
Q: What breaks when Kubernetes authentication relies on static credentials?
A: Static credentials break the governance model because access persists until someone finds and revokes the secret.
Practitioner guidance
- Tighten namespace-scoped RBAC Review every Kubernetes role and cluster role binding for namespace overreach, especially where shared admin groups or service accounts can cross regulated workloads.
- Replace persistent access with ephemeral access flows Use short-lived authentication and session-based access for Kubernetes administration so operators do not rely on reusable passwords, tokens, or API credentials.
- Map regulated workloads to separate evidence trails Require audit logs and session records at the namespace level for workloads handling payment, production, or other sensitive data.
What's in the full article
Teleport's full blog post covers the operational detail this post intentionally leaves for the source:
- Namespace restriction patterns for Kubernetes clusters used in financial services environments
- Teleport's explanation of RBAC, multi-tenancy, and session recording in practical deployment terms
- How its approach maps to compliance requirements under PCI DSS and DORA
- Infrastructure access scenarios across cloud, on-premises, and hybrid environments
👉 Read Teleport's analysis of Kubernetes namespace separation and compliance →
Kubernetes namespace separation: what IAM teams need to govern?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
17/08/2026 4:47 pm
Namespace separation is only as strong as the identity layer that enforces it. Kubernetes gives organisations a logical boundary, but that boundary collapses when access is still expressed through broad roles, persistent credentials, or shared administrative paths. Financial services teams should read namespace separation as an identity governance problem first and a platform pattern second.
A few things that frame the scale:
- 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: Who is accountable for namespace separation failures under PCI DSS and DORA?
A: Accountability sits with the organisation that owns the environment and the identity controls around it, not just with platform operators. PCI DSS and DORA both push teams toward demonstrable control, so the accountable group must be able to explain who had access, why it was granted, and how it was removed.
👉 Read our full editorial: Kubernetes namespace separation exposes the identity gap in compliance
