I am facing the issue while creating a NAP node pool through Azure portal

Hello @cargobuddy

1. Private DNS Zone is not linked to your VM's subnet (most likely root cause).

When AKS creates a private cluster, it automatically creates a Private DNS Zone (something like privatelink.<region>.azmk8s.io) and links it to the AKS VNet. The problem is that this DNS zone is only linked to the AKS VNet by default — not to your VM's subnet, even if both are in the same VNet.

Without this DNS link, your VM can't resolve the private FQDN of the API server, so kubectl commands silently fail or time out, and the portal can't reach the cluster to display nodes/pods either.

To verify and fix this, run:

Check if your VNet has the DNS zone linked

az network private-dns link vnet list \
 --resource-group <AKS_NODE_RESOURCE_GROUP> \
 --zone-name <your-private-dns-zone>

If your VM's VNet isn't listed, add the link:

az network private-dns link vnet create \
 --resource-group <AKS_NODE_RESOURCE_GROUP> \
 --zone-name <your-private-dns-zone> \
 --name MyVNetLink \
 --virtual-network <YOUR_VNET_ID> \
 --registration-enabled false

Create a private AKS cluster – DNS configuration options
https://learn.microsoft.com/en-us/azure/aks/private-cluster#options-for-connecting-to-the-private-cluster

2.Azure RBAC role on the AKS resource itself

Yes, to answer your question directly — the identity you're using on the bastion VM does need a specific Azure role on the AKS cluster resource (not just inside Kubernetes). Without Azure Kubernetes Service Cluster User Role (or Cluster Admin Role), you can't even run az aks get-credentials to pull down the kubeconfig.

Assign it like this:

AKS_ID=$(az aks show \
 --resource-group <RESOURCE_GROUP> \
 --name <CLUSTER_NAME> \
 --query id -o tsv)
az role assignment create \
 --assignee <USER_OR_MANAGED_IDENTITY_PRINCIPAL_ID> \
 --role "Azure Kubernetes Service Cluster User Role" \
 --scope $AKS_ID

Then pull the credentials *from the bastion VM itself:

az login # or use managed identity: az login --identity
az aks get-credentials --resource-group <RG> --name <CLUSTER_NAME>
kubectl get pods --all-namespaces

Use Azure RBAC for Kubernetes authorization
https://learn.microsoft.com/en-us/azure/aks/manage-azure-rbac

3.NSG rules between subnets

Since your VM and AKS nodes are in different subnets (even within the same VNet), NSG rules can block the required traffic. Make sure outbound TCP port 443 is allowed from your VM's subnet toward the AKS subnet (where the private endpoint lives). You can verify the private endpoint IP with:

Azure PowerShell

az network private-endpoint show \
 --name <PRIVATE_ENDPOINT_NAME> \
 --resource-group <AKS_NODE_RESOURCE_GROUP> \
 --query 'customDnsConfigs[].ipAddresses'

About the Azure Portal behavior

The fact that the portal shows the cluster but not individual nodes or pods is actually expected for private clusters the portal's backend can't reach your private API server endpoint. To manage it through the portal, you can use the built-in Run Command feature (under the cluster's overview → "Run command"), which proxies commands through Azure without needing direct network access.

Use the Run command for private AKS clusters:
https://learn.microsoft.com/en-us/azure/aks/access-private-cluster

Additional references:

https://learn.microsoft.com/en-us/azure/aks/private-cluster https://learn.microsoft.com/en-us/azure/aks/concepts-identity

https://learn.microsoft.com/en-us/azure/aks/private-cluster#configure-private-dns-zone

Thanks,
Manish.

Hello @cargobuddy

I wanted to check if my last response made sense. I’d be glad to assist further or explain anything in more detail