One challenge of managed Kubernetes is that it puts the control plane in the hands of the cloud provider, but you still own the identity risks.
Services like Amazon Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS), and Google Kubernetes Engine (GKE) have transformed application deployment. But these cloud providers manage the control plane, not your access risk.
Why it Matters: Kubernetes role-based access control, or RBAC, and cloud identity and access management, or IAM, often operate as separate access layers. As permissions accumulate and standing privileges persist across those layers, security teams lose sight of what an identity can reach (or become) across the cluster and cloud.
The Threat: Unit 42 found that frontier models can rapidly identify overprivileged accounts and unmanaged tokens that enable lateral movement. Its Kubernetes research showed how one stolen service-account identity with excessive permissions could create a path from one workload into the cluster and wider cloud environment.
The Gap: Native Kubernetes RBAC relies on static Roles and RoleBindings. When teams map cloud IAM directly to cluster permissions at scale, they inevitably create standing privileges.
On one side, human developers require access to command-line interface, or CLI, to debug microservices. On the other, automated CI/CD pipelines rely on long-lived kubeconfig credentials to ship code. As teams introduce delegated AI agents to assist with operations, the attack surface expands even further. For security leaders, the question is not just who can access the cluster. It’s what that identity can become and how far it can reach.
The question is not just who can access the cluster. It’s what that identity can become and how far it can reach.
What You Can Do: In this blog, we'll show you how organizations can enforce cluster security across modern Kubernetes environments by moving away from static keys, base64-encoded native secrets, and permanent roles toward a unified identity security model.
Managed Kubernetes Demands Modern Privileged Access Management
In managed Kubernetes, any identity that can change the cluster or reach a sensitive resource carries privilege.
But traditional privileged access management, or PAM, was designed for a world of static human accounts vaulting passwords for legacy servers. Managed Kubernetes highlights exactly why that legacy approach breaks down in containerized cloud environments.
Modern PAM must evolve to protect three distinct identity types that take privileged actions across cloud infrastructure:
- Human Identities: Developers, site reliability engineers, or SREs, and IT administrators requesting just-in-time elevation and terminal-level cluster access without static standing roles.
- Machine Identities: Containerized workloads, pods, and CI/CD deployment pipelines requiring secretless, cryptographic authentication to external cloud services and databases.
- Agentic Identities: Autonomous AI agents executing operational workflows on behalf of developers while inheriting identical session boundaries, access scoping, and command audits.
By bringing all three identity types under a single modern PAM framework, security teams can reduce operational silos and enforce ZSP across the entire cloud lifecycle.
Automated Discovery: Unifying Cloud IAM and Shadow Secrets
Effective access, not assigned roles, defines Kubernetes risk.
Securing managed Kubernetes starts with complete visibility into existing roles and workloads. The mechanics differ by provider: Cloud IAM roles (such as AWS IAM mapped via aws-auth or Azure RBAC) now sit directly on top of native Kubernetes RBAC policies, bridging two entirely different access models.
The Idira® Identity Security Platform automatically scans and maps cloud IAM roles assigned to Kubernetes clusters and namespaces, helping teams create ZSP policies for discovered roles while eliminating manual, error-prone onboarding.
At the same time, it discovers machine identities across your infrastructure, exposing static API keys, shadow secrets deployed via Infrastructure as a Service and Infrastructure as Code templates, and unmanaged service accounts hiding in pipelines and containerized environments.
Control Inbound Cluster Access: JIT Scoping for Developers and Delegated AI Agents
Cluster access should last only as long as the work requires. But security controls shouldn't force developers out of their natural workflows.
With Idira, developers authenticate directly in their native terminal using familiar idsec CLI commands (idsec login, idsec k8s clusters list, idsec k8s kubeconfig generate) to generate short-lived credentials.
Cluster access should last only as long as the work requires.
Access is scoped with granular precision down to the namespace level. Instead of relying on permanent, static Kubernetes RoleBindings, developers only view and interact with authorized namespaces—such as inspecting logs in payments while remaining isolated from analytics. When elevated access is required for maintenance or break-glass outage response, teams grant JIT access backed by full kubectl exec session recording for compliance.
Control Outbound Cluster Access: Secretless Authentication with OIDC and JWT-SVIDs
Securing access into the cluster is only half the equation; containerized workloads must also authenticate out to external cloud services and databases.
Native Kubernetes Secrets are inherently vulnerable. They are fundamentally just base64-encoded strings, not encrypted vaults. This makes hardcoded credentials a significant risk if a pod is compromised.
Idira helps eliminate long-lived static secrets across deployment pipelines and workloads. CI/CD systems like GitHub Actions or GitLab use short-lived OpenID Connect tokens, or OIDC, for secretless deployments. For pod-to-cloud authentication, workloads attest to Idira Secrets Manager to receive short-lived JWT-SVIDs, or SPIFFE Verifiable Identity Documents in JWT format. Pods can use their JWT-SVID to directly access external services that support OIDC; otherwise, they can use it to dynamically fetch the exact credentials required for external services from Idira Secrets Manager. This reduces the need to store static secrets in Kubernetes and the overhead of manually managing long-lived certificates.
Govern and Unify: One Multi-Cloud Operating Model Across EKS, AKS, and GKE
During a critical production outage, SREs shouldn't have to jump between access tools. Using Idira Secure Cloud Access, engineers receive temporary, unified access to both cluster pods and backend databases through a single privileged workflow.
By standardizing governance across EKS, AKS, and GKE, organizations can achieve consistent zero standing privilege policies regardless of where workloads run. Connectors deploy seamlessly through Helm or Argo CD, bringing complete visibility, zero standing privilege, and automated control to managed Kubernetes infrastructure.
The Bottom Line: The cloud provider may manage the control plane, but your organization still owns the identity risk.
By continuously discovering access, controlling privilege, and governing how human, machine, and agentic identities use it, you give attackers less access to inherit and fewer paths to move through.
The work continues as organizations add new clusters, workloads, and AI agents. Teams must regularly reassess permissions and refine policies to prevent today’s temporary access from becoming tomorrow’s standing privilege.
See Managed Kubernetes Identity Security in Action
Request a live demo to see how Idira eliminates standing privileges across your AWS EKS and Azure AKS environments. Or check out the solution brief to learn how to enforce ZSP for developers, workloads, and CI/CD pipelines.
FAQs
What is zero standing privileges in Kubernetes?
Zero Standing Privileges (ZSP) is an access model where no user, machine workload, or AI agent retains permanent administrative or cluster access. Permissions are granted dynamically on a just-in-time (JIT) basis, restricted to specific namespaces, and automatically revoked when the task is complete.
Why are native Kubernetes Secrets considered insecure?
Native Kubernetes Secrets are merely base64-encoded plain text stored in etcd. They are not encrypted vaults. If a pod or repository is compromised, attackers can easily decode static native secrets to gain unauthorized access to external cloud databases.
How does Idira secure agentic AI identities in Kubernetes?
Idira applies the same session boundaries, namespace scoping, and command auditing to autonomous AI agents as it does to human developers, ensuring AI operational workflows execute strictly with short-lived, least privilege permissions.
Why isn’t Kubernetes RBAC enough on its own?
Kubernetes RBAC controls permissions inside the cluster, while cloud IAM governs access across the provider environment. Security teams need visibility and consistent controls across both layers to understand an identity’s full reach.