Secure Native Access to Azure Kubernetes Service (AKS) Private Clusters with Azure Bastion

Written in Collaboration with AvirupChat, ShabazShaik, Mohit_Kumar, YuriDiogenes

As companies increasingly adopt containerized solutions like Azure Kubernetes Service (AKS), ensuring secure access to cluster resources is vital. Making the Kubernetes API server private considerably lowers the risk of attacks. However, this shift also affects how engineers carry out routine management tasks. Everyday operations such as running kubectl logs, checking resource descriptions, or troubleshooting workloads now require a connection to the virtual network housing the cluster.

This issue becomes especially noticeable during daily operations. An engineer may have the appropriate Kubernetes credentials and Azure RBAC permissions but still struggle to access the cluster since the API server is only reachable from the private network. Setting up VPN connections, using jump hosts, or deploying specific management workstations often complicates what should be simple administrative tasks.

Azure Bastion’s native client tunneling support for private AKS clusters effectively addresses this balance between maintaining robust network isolation and facilitating smooth cluster management.

Many Azure users rely on Azure Bastion to securely access virtual machines without exposing them to the public internet. Now, with native client tunneling, that same secure access model is extended to private AKS clusters. This feature is currently in public preview. Before delving into how it works, let’s look at the operational challenges it resolves and the process involved.

At its core, Azure Bastion simplifies secure access to private Azure resources. Since its inception, it has offered browser-based and native client RDP and SSH connectivity to Azure VMs without exposing management ports to the internet. No public IPs on your VMs, no inbound NSG rules for ports 22 or 3389—only TLS over port 443 routed through a fully managed service that Microsoft handles, patches, and secures for you.

When you create a Bastion tunnel to your private AKS cluster, you’re not signing into a middleman machine to run kubectl commands. Instead, you establish an encrypted tunnel directly from your local device through Bastion to the private API server endpoint. Your kubeconfig configures to point to localhost on a dynamically assigned port, allowing local kubectl, helm, and scripts to operate like they would with a public cluster.

This setup gives you the developer experience of a public cluster while maintaining the security of a private one, as depicted in Figure 1.

The process consists of three main stages: The engineer authenticates with Azure, retrieves cluster credentials, and then uses Azure Bastion to create a managed tunnel into the private network. Local Kubernetes tools can then leverage that tunnel to access the private API server. This keeps the workflow familiar while removing the need for jump hosts or VPNs.

But this raises an essential question: Does making access easier also open the door for attackers?

The short answer is no. In fact, Bastion tunneling enhances your security measures in several ways worth exploring.

Firstly, the API server itself remains private. There’s no public endpoint or discoverable public IP address. The only network route to the API server goes through Azure’s managed infrastructure, with authentication and authorization reliant on the AKS cluster setup.

Secondly, Bastion eliminates an entire class of infrastructure that can be a target for security breaches. Jump host VMs, if not meticulously maintained, can gather credentials, kubeconfig files, and browser sessions, exposing vulnerabilities. Bastion is not a machine you log into; it functions as an agentless, managed tunnel for secure passage.

For public clusters, another significant benefit arises. Many teams restrict access to authorized IP ranges for the public API endpoint, a good practice that can falter when faced with remote work or dynamic IPs. By incorporating Bastion’s stable public IP into the authorized range, you create a consistent, manageable access path without the hassle of constantly updating IP lists.

With the network path established via Bastion, the next step is understanding how users are authenticated and authorized once they access the AKS API server. This distinction is crucial: Bastion provides secure connectivity while AKS access follows the authentication and authorization model configured on the cluster.

When setting up an AKS cluster, you can select from three authentication and authorization modes, as illustrated in the figure below.

Local accounts with Kubernetes RBAC is the default option if no changes are made. This employs a static certificate that never expires, shared among all administrators, and is unrelated to your corporate identity provider. It lacks MFA and Conditional Access.

Note: For most production scenarios, Microsoft suggests using Microsoft Entra ID integrated authentication instead of local accounts for centralized identity, MFA, and auditing.

Microsoft Entra ID with Kubernetes RBAC shifts authentication to Entra ID, allowing users to sign in with their corporate credentials, enforce MFA, and apply Conditional Access policies. Authorization is managed through Kubernetes Role and ClusterRole bindings, which refer to Entra ID users and groups as subjects. This setup is beneficial for teams managing cluster configurations via GitOps, as RBAC manifests reside alongside other cluster configurations. A downside is that these permissions are hidden in Azure IAM—they exist only within the cluster.

Microsoft Entra ID with Azure RBAC is the preferred model for most production settings. Authentication still runs via Entra ID, maintaining full MFA and Conditional Access support. Authorization is managed through Azure RBAC role assignments on the AKS resource, allowing permissions to be visible in Azure IAM and participate in access reviews. The Privileged Identity Management feature also enables just-in-time elevation. You can assign built-in Azure Kubernetes Service RBAC Cluster Admin, Admin, Writer, or Reader roles at either the cluster or namespace level. A single subscription-level role assignment can grant access to all clusters in that subscription.

The real benefit lies in the synergy. Bastion provides the encrypted network tunnel, Entra ID offers identity management, MFA, and Conditional Access, while Azure RBAC ensures centralized, auditable authorization that your security team can assess alongside other Azure resources.

To correctly set up Entra ID authentication and Azure RBAC on your AKS cluster, refer to the AKS identity documentation.

 az account set –subscription

Use the following commands to retrieve credentials for your AKS private cluster:

az aks get-credentials –name –resource-group

Now, open the tunnel to your target AKS Cluster with this command:

az aks bastion –name –resource-group –bastion

The default authentication method is Device code authentication, prompting the user to sign in via a browser. If you prefer CLI-only authentication, run the following:

kubelogin convert-kubeconfig -l azurecli

Then proceed with your AKS connectivity:

kubectl get nodes

If you’re already using private AKS clusters, getting started is simple. Ensure you have a Standard or Premium Azure Bastion host deployed in the same VNet as your cluster (or a peered VNet) with native client support enabled. The aks-preview and bastion CLI extensions will take care of the rest.

For detailed connection steps, check out Microsoft Learn.

We’d love to hear from you! Drop a comment below or open an issue in the AKS GitHub repository, or provide feedback directly on the Microsoft Learn documentation page. Your input truly helps us prioritize improvements.