The Security Mandate: Why Permanent Access Fails Mission-Critical AKS
Kubernetes has become the operating system of the cloud, hosting an enterprise’s most critical and sensitive workloads. For platform engineers, developers, and SREs to perform their jobs, they require high levels of access—often to the Kubernetes API server and its core resources.
The traditional approach of granting permanent, or “standing,” access to Azure Kubernetes Service (AKS) clusters creates a massive and unacceptable security risk. This standing privilege model is vulnerable to compromise, allowing lateral movement for an attacker using a stolen token or credential. Security best practices, including compliance frameworks like PCI DSS 4.0.1, explicitly require minimizing standing privileges and adopting Just-in-Time (JIT) access.
The recommended and most robust security model for AKS is Microsoft Entra ID integration combined with Azure RBAC (Role-Based Access Control). This approach simplifies role assignment and management by unifying identity and authorization. Our new JIT Kubernetes product is explicitly designed to leverage and enforce this best-practice architecture, focusing on authentication and authorization for managed Kubernetes services, specifically AKS.
Deep Dive: Granular Control with Just-In-Time Kubernetes
JIT Kubernetes is not just a gate; it is a specialized authorization engine that applies the principle of Zero Standing Privilege (ZSP) directly to your Kubernetes resources. It is end-to-end ready for Azure and enables a shift from always-on access to temporary, context-aware permissions.
Granular Control: Cluster vs. Namespace
The power of JIT Kubernetes lies in its precision, allowing you to scope access to the minimal resources required for any desired task. The solution supports requests at two crucial levels of granularity:
- Cluster-Level Roles: Primarily for platform teams performing infrastructure-wide upgrades and maintenance.
- Namespace-Level Roles: For development teams who only need access to deploy, scale, or troubleshoot applications within their specific namespace.
Custom RBAC Roles: Security Without Compromise
A major limitation of many security tools available is their reliance on default or pre-defined roles. Cloudanix’s JIT Kubernetes goes a step further by supporting custom RBAC roles.
This feature enables security and platform teams to precisely craft highly specific permissions for unique business needs. For instance, you can create a custom “writer” role that is explicitly defined to deploy containers but is simultaneously restricted from accessing sensitive Kubernetes Secrets. JIT Kubernetes supports enforcing these detailed permissions in addition to the four predefined Azure roles, provided they are properly configured in the settings.
The Seamless Request Flow
The user experience for requesting access is designed for operational efficiency, similar to our other JIT products.
- A user selects the appropriate group and chooses the desired role (e.g., Reader, Contributor, or a custom role).
- They specify the scope: the entire cluster or a specific namespace.
- Upon approval, the JIT Kubernetes solution applies the role at the required level, and the user can verify their permissions to access resources accordingly.
- Once the time-bound access window expires, permissions are automatically and audibly revoked.
Overcoming Technical Challenges
Successfully applying JIT access to Kubernetes at an enterprise level requires resolving complex network and onboarding challenges.
Cluster Endpoint Modes
AKS clusters can be deployed with different endpoint modes, each posing unique connectivity challenges:
- Public and Semi-Private Clusters: These clusters are currently supported by the JIT Kubernetes solution for seamless authentication and authorization.
- Private Clusters: These clusters do not expose a public API endpoint. Access typically requires connecting via a virtual network (VNet) or an intermediary jump box. Our team is actively addressing this technicality by planning to extend JIT to tunneling via a VM, offering a secure alternative if customers are reluctant to whitelist their corporate VPN IP addresses.
Implementation Prerequisites
To ensure a successful and secure onboarding for Kubernetes JIT, enterprise users must complete the necessary backend prerequisites:
- Backend Mapping: Due to the complexity of the security model, group-to-cluster or group-to-namespace mappings must be configured using APIs (as the UI setting screen is yet to be built).
- Namespace Data: Namespace data is not automatically obtained from inventory and must be explicitly provided by the customer for proper onboarding.
Roadmap and Future Vision
JIT Kubernetes is a continuously evolving product. While it is fully end-to-end ready for Azure and supports most AKS versions, our focus is rapidly expanding to cover the multi-cloud enterprise:
- Multi-Cloud Expansion: Work on AWS is actively underway, with the backend completed and console integration in progress.
- On-Premise Feasibility: Technical feasibility exists to support on-premise or bare metal Kubernetes setups, with the potential to provide even more features in those environments.
- Immediate Next Steps: The next planned steps include building the dedicated settings screen and deploying the JIT to VM tunneling capability for private cluster access.
Conclusion: Securing the Future of AKS
The deployment of JIT Kubernetes for Azure marks a significant step toward achieving true Zero Standing Privilege in cloud-native environments. By shifting access from a permanent security risk to a temporary, auditable, and highly granular transaction, your organization can simultaneously enhance security, simplify compliance, and maintain the agility that modern DevOps and MLSecOps teams demand.
It’s time to eliminate standing access and secure your AKS clusters with the power of Just-in-Time access.
