Private AKS Clusters in Azure

What makes a cluster “private”

In a standard AKS cluster, the Kubernetes API server has a public FQDN like my-cluster-dns-12345.hcp.eastus.azmk8s.io that resolves to a public IP. Anyone on the internet can send requests to it (though they still need valid credentials to authenticate).

A private AKS cluster creates the API server behind a private endpoint inside your VNet. The API server’s FQDN resolves to a private IP address (from your VNet subnet). No public IP exists. The API server is completely unreachable from outside your VNet.

The worker nodes communicate with the API server via private IP as well, since they are in the same VNet. Nothing changes for pod-to-pod or pod-to-service communication — only the management plane (kubectl access) changes.

Creating a private cluster

# Create the VNet and subnet first (best practice for production)
az network vnet create \
  --resource-group my-aks-rg \
  --name my-vnet \
  --address-prefix 10.0.0.0/8 \
  --subnet-name aks-subnet \
  --subnet-prefix 10.240.0.0/16

SUBNET_ID=$(az network vnet subnet show \
  --resource-group my-aks-rg \
  --vnet-name my-vnet \
  --name aks-subnet \
  --query id -o tsv)

# Create the private AKS cluster
az aks create \
  --resource-group my-aks-rg \
  --name private-cluster \
  --enable-private-cluster \
  --vnet-subnet-id $SUBNET_ID \
  --network-plugin azure \
  --enable-managed-identity \
  --generate-ssh-keys

After creation, note that the cluster now has two FQDNs:

• A private FQDN that resolves to a private IP within the VNet
• No public FQDN at all (unlike the hybrid mode described below)

# Verify the cluster has no public FQDN
az aks show \
  --resource-group my-aks-rg \
  --name private-cluster \
  --query "privateFqdn" -o tsv

# This returns the private API server address
# e.g., private-cluster-abcd1234.privatelink.eastus.azmk8s.io

Connecting kubectl to a private cluster

Because the API server is private, you cannot run az aks get-credentials and connect directly unless your machine is in the same VNet (or connected via VPN/ExpressRoute).

The fastest option for getting started is the Azure CLI command tunnel:

# Use the Azure CLI to establish a tunnel to the private API server
az aks command invoke \
  --resource-group my-aks-rg \
  --name private-cluster \
  --command "kubectl get nodes"

# The command-invoke approach runs kubectl on Azure's infrastructure
# It does not require VPN or VNet connectivity from your local machine

For regular day-to-day use, set up proper network connectivity. Options:

• Azure VPN Gateway — site-to-site or point-to-site VPN from your office or developer machines
• Azure Bastion + Jump VM — a VM inside the VNet with a Bastion connection. Developers SSH to the jump VM and run kubectl there.
• Azure ExpressRoute — private circuit from on-premises data center to Azure VNet
• GitHub Codespaces or Azure Container Apps in VNet — for CI/CD pipelines and developer environments

Private DNS configuration

Private clusters use Azure Private DNS zones to resolve the API server FQDN to a private IP. AKS creates and manages this DNS zone automatically by default.

For environments where you manage DNS centrally:

# Create the cluster with custom private DNS zone
az aks create \
  --resource-group my-aks-rg \
  --name private-cluster \
  --enable-private-cluster \
  --private-dns-zone /subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Network/privateDnsZones/privatelink.eastus.azmk8s.io \
  --generate-ssh-keys

# Or use the system-managed zone (simplest)
az aks create \
  --resource-group my-aks-rg \
  --name private-cluster \
  --enable-private-cluster \
  --private-dns-zone system \
  --generate-ssh-keys

If you have VNet peering, the private DNS zone needs to be linked to the peered VNets for the API server to be resolvable from those networks:

# Link a private DNS zone to a peered VNet
az network private-dns link vnet create \
  --resource-group MC_my-aks-rg_private-cluster_eastus \
  --zone-name "privatelink.eastus.azmk8s.io" \
  --name my-vnet-link \
  --virtual-network /subscriptions/{sub}/resourceGroups/other-rg/providers/Microsoft.Network/virtualNetworks/other-vnet \
  --registration-enabled false

Hybrid: private cluster with public FQDN option

For some scenarios — like CI/CD pipelines that run outside your VNet but need to deploy to the cluster — you can enable a public FQDN alongside the private endpoint. This does not re-expose the API server to the internet in the traditional sense; it still requires Azure AD authentication, but it resolves over the public internet:

# Enable public FQDN alongside private endpoint
az aks update \
  --resource-group my-aks-rg \
  --name private-cluster \
  --enable-public-fqdn

# Or start with public FQDN disabled and enable it later if needed
az aks update \
  --resource-group my-aks-rg \
  --name private-cluster \
  --disable-public-fqdn

Alternative: authorized IP ranges on public clusters

If a fully private cluster is too complex for your environment, you can restrict API server access to specific IP addresses on a public cluster:

# Create cluster with IP restrictions on API server
az aks create \
  --resource-group my-aks-rg \
  --name restricted-cluster \
  --api-server-authorized-ip-ranges "203.0.113.0/24,198.51.100.10/32" \
  --generate-ssh-keys

# Update IP ranges on existing cluster
az aks update \
  --resource-group my-aks-rg \
  --name restricted-cluster \
  --api-server-authorized-ip-ranges "203.0.113.0/24"

# Remove restrictions (re-open to all IPs - use with caution)
az aks update \
  --resource-group my-aks-rg \
  --name restricted-cluster \
  --api-server-authorized-ip-ranges ""

Authorized IP ranges are a good middle ground for teams that need public API access but want to limit it to known networks like office IPs or CI/CD runner IPs. The API server still has a public IP but only accepts connections from the allowlisted ranges.

CI/CD with private clusters

The most common challenge with private clusters is making CI/CD pipelines work. For Azure DevOps and GitHub Actions, the recommended pattern is a self-hosted agent/runner deployed inside the VNet:

# Deploy a self-hosted GitHub Actions runner in the VNet
# (Use the ARC - Actions Runner Controller)
helm repo add actions-runner-controller \
  https://actions-runner-controller.github.io/actions-runner-controller
helm repo update

helm install arc \
  --namespace arc-systems \
  --create-namespace \
  actions-runner-controller/actions-runner-controller \
  --set authSecret.create=true \
  --set authSecret.github_token="<your-github-pat>"

# Create a runner that has VNet access to the private cluster
cat <<EOF | kubectl apply -f -
apiVersion: actions.summerwind.dev/v1alpha1
kind: RunnerDeployment
metadata:
  name: github-runner
  namespace: arc-systems
spec:
  replicas: 2
  template:
    spec:
      repository: my-org/my-repo
      image: summerwind/actions-runner:latest
EOF