AKS Private Cluster - Azure Portal Unable to Display Kubernetes Resources

Question

AKS Private Cluster - Azure Portal Unable to Display Kubernetes Resources

Francisco Ruano 20

I have an AKS private cluster where Azure Portal cannot display Kubernetes resources (Pods, Deployments, Services, etc.), even though connectivity to the cluster is working correctly.

The issue appears only in the Azure Portal Kubernetes Resource View.

Cluster Information

Affected Cluster

AKS Private Cluster
Kubernetes Version: 1.35.6
Network Plugin: Azure CNI
Network Plugin Mode: Overlay
Azure RBAC Enabled: True
Private DNS Zone: system
Private Cluster Public FQDN: Enabled

Working Cluster for Comparison

AKS Private Cluster
Kubernetes Version: 1.33.12
Network Plugin: Azure CNI
Network Plugin Mode: Node Subnet (non-overlay)

Problem Description

When accessing:

AKS -> Settings-> Node Pools -> Node pool -> Nodes

the portal fails to load resources.

User's image

The browser developer console shows errors similar to:

Access to fetch has been blocked by CORS policy:

Permission was denied for this request to access the 'local' address space.

User's image

The failing requests are directed to:

https://<cluster-id>.priv.portal.hcp.southcentralus.azmk8s.io

Connectivity Validation Performed

VPN

Connected through Azure Point-to-Site VPN.

Kubernetes Access

The cluster is fully accessible using kubectl:

kubectl get nodes

kubectl get pods -A

Both commands execute successfully.

RBAC

My user has the role:

Azure Kubernetes Service RBAC Cluster Admin

DNS Resolution

The Portal endpoint resolves correctly:

PowerShell

Resolve-DnsName <cluster-id>.priv.portal.hcp.southcentralus.azmk8s.io

User's image

Network Connectivity

PowerShell

Test-NetConnection <cluster-id>.priv.portal.hcp.southcentralus.azmk8s.io -Port 443

User's image

HTTPS Validation

Executed:

PowerShell

curl.exe -vk https://<cluster-id>.priv.portal.hcp.southcentralus.azmk8s.io

User's image

This demonstrates:

DNS resolution works
Routing works
VPN connectivity works
TLS negotiation succeeds
The endpoint is reachable and responding

AKS Diagnostics

Azure Portal → Diagnose and Solve Problems → Connectivity Issues

All connectivity checks completed successfully with no reported failures.

Browser Testing

Issue reproduced in:

Microsoft Edge
Google Chrome
Mozilla Firefox

Therefore the issue does not appear to be browser-specific.

Expected Behavior

Azure Portal should display Pods and other Kubernetes resources when connected through VPN and with appropriate RBAC permissions.

Actual Behavior

Azure Portal fails to display Kubernetes resources and browser requests to:

*.priv.portal.hcp.southcentralus.azmk8s.io

fail with CORS / local address space related errors.

Request

Please investigate the Azure Portal Kubernetes Resource View integration and the associated:

*.priv.portal.hcp.southcentralus.azmk8s.io

endpoint for this AKS cluster.

Based on the validation performed, networking, DNS, VPN access, RBAC permissions, and API server reachability appear to be functioning correctly, while only the Portal resource view is affected.

Akram Kathimi 2,001 Reputation points Microsoft Employee

2026-08-03T06:35:21.8766667+00:00

Hi @Francisco Ruano , Thank you for posting this question. This is an expected behavior when accessing resources for a private AKS cluster from the portal.

To be able to access the AKS private cluster, your machine should be in the same VNET or in a peered VNET to the AKS cluster VNET. This usually means using a VPN to access Azure Resources.

As I understand, you are able to reach the resources using kubectl, but not the portal resources. If this was the same machine, I would reach to your networking team to check if there is a different configuration between *.priv.portal.hcp.southcentralus.azmk8s.io and *.privatelink.southcentralus.azmk8s.io

Please check this document for more information.

Thanks.

1 answer

Your answer

Akram Kathimi 2,001 Reputation points Microsoft Employee

2026-08-03T06:35:21.8766667+00:00

Hi @Francisco Ruano , Thank you for posting this question. This is an expected behavior when accessing resources for a private AKS cluster from the portal.

To be able to access the AKS private cluster, your machine should be in the same VNET or in a peered VNET to the AKS cluster VNET. This usually means using a VPN to access Azure Resources.

As I understand, you are able to reach the resources using kubectl, but not the portal resources. If this was the same machine, I would reach to your networking team to check if there is a different configuration between *.priv.portal.hcp.southcentralus.azmk8s.io and *.privatelink.southcentralus.azmk8s.io

Please check this document for more information.

Thanks.

Answer 1

Hello @Francisco Ruano

Based on the information provided, this looks less like a networking issue and more like an issue with the Azure Portal Kubernetes Resource View for this specific cluster configuration.

Since:

kubectl connectivity works correctly.
The problem only occurs in the Azure Portal.
Azure RBAC is enabled.
The cluster is private but has a Private Cluster Public FQDN enabled.
The primary differences from the working cluster are Kubernetes 1.35.6 and Azure CNI Overlay.

I'd recommend checking the following:

Verify Azure RBAC and Kubernetes RBAC

Ensure your account has an Azure role such as Azure Kubernetes Service RBAC Cluster Admin or Cluster User, along with the required Kubernetes permissions to view cluster resources.

Inspect the browser network trace

Open the browser Developer Tools (F12) and check for failed requests (401, 403, 404, or 500) when loading the Kubernetes Resource View. Also capture the x-ms-correlation-request-id, which is valuable for support.

Confirm the issue isn't client-specific

Test using an InPrivate/Incognito session or another browser to rule out cached portal artifacts.

Compare the cluster configuration

Since the older AKS cluster (1.33.12, Azure CNI node subnet mode) works while the newer cluster (1.35.6, Azure CNI Overlay) does not, this may indicate a regression in the portal integration rather than a cluster configuration issue. Azure CNI Overlay is now the default networking mode for new AKS clusters, so this difference is worth highlighting in your support request.

If CLI access works, open a support request

If commands such as:

kubectl get nodes

kubectl get pods -A

kubectl get deployments -A

all succeed while only the Azure Portal fails to render resources, the Kubernetes API server is functioning correctly. This strongly suggests an Azure Portal backend or integration issue rather than a problem with the private cluster itself.

When opening a support case, include:

Cluster Resource ID
Kubernetes version (1.35.6)
Network plugin (Azure CNI Overlay)
Browser HAR/F12 logs
Correlation ID from the failed portal request

Output of:

  *az aks show -g <resource-group> -n <cluster-name>*

 *kubectl version*

 *kubectl cluster-info*

There have been previous reports where the Azure Portal Kubernetes Resource View experienced issues specifically with private AKS clusters, even though direct kubectl access remained fully functional, making this pattern consistent with a portal-side issue rather than a cluster networking problem.

Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.