Connecting-Securely-to-AKS-Private-Cluster

Why You Can’t See the NIC or Private IP of the Cloud Shell Container

Even though the Cloud Shell container runs inside your VNet, its network interface is not exposed to you. Here’s why:
1. Cloud Shell Is a Managed Service
- The container is provisioned and controlled entirely by Microsoft.
- You don’t own the container group or its NIC—so it doesn’t show up in your subscription.

2. No Resource Visibility
- The NIC is created in the background, but it’s not listed under your az network nic list.
- You won’t see it in the Azure Portal, Resource Graph, or CLI.
3. Ephemeral and Isolated
- The container is short-lived and isolated.

🌐 Network Flow: Cloud Shell in VNet → AKS Private Cluster via Azure Relay

1. Cloud Shell Container Gets an IP from the Container Subnet
- When Cloud Shell is deployed in a VNet, it runs inside an Azure Container Instance (ACI).
- This ACI is assigned a private IP address from the container subnet you specify.
- This subnet must be part of the same VNet—or peered to the VNet where your AKS cluster resides.

2. Azure Relay Facilitates Secure Connectivity
- Azure Relay acts as a secure tunnel between your browser session and the Cloud Shell container.
- It does not route traffic to AKS itself—it simply allows your browser to interact with the container running inside the VNet.

3. Cloud Shell Container Connects Directly to AKS
- Once inside the VNet, the Cloud Shell container can directly access the AKS API server via its private endpoint (usually on port 443 or 6443).
- This works because:
- The container has a private IP in the same network space.
The AKS cluster is reachable via private DNS or a private link.

Why we connect to Endpoint API via 443 and not 6443

AKS utilizes a load balancer configured to allow inbound traffic on port 443.

🔌Azure Relay Acts as a Bi-directional Proxy—but Only for the Browser ↔ Container Path

1. Cloud Shell Container Is Deployed Inside Your VNet
- It gets a private IP from the container subnet.
- It can access private resources like AKS, VMs, etc.
2. Azure Relay Is Used by Microsoft to Reach the Container
- Azure Relay is not accessed by your resources.
- Instead, Microsoft’s infrastructure uses Azure Relay to connect your browser session to the container.
- This is done via a hybrid connection, which allows two endpoints that aren’t directly reachable to communicate securely.
3. Private Endpoint for Azure Relay Is Deployed in Your VNet
- This gives Azure Relay a private IP inside your VNet.
- Azure uses this private IP to reach the Cloud Shell container from its own infrastructure.
- The traffic flow is initiated by Azure Relay (on behalf of your browser), not by your resources.

🔁 Summary of Flow of Azure Relay

User Browser (Internet)
↓
Azure Portal
↓
Azure Relay (Private Endpoint in VNet, with private IP)
↓
Cloud Shell Container (Private IP in container subnet)
↓
AKS Private Cluster (Private IP in AKS subnet)

🔐 Key Insight

Azure Relay’s private endpoint is used by Microsoft’s infrastructure, not by your resources. It allows Azure to inject traffic into your VNet to reach the Cloud Shell container. This design cleverly bypasses the limitation of private endpoints being inbound-only—because the inbound traffic is initiated by Azure Relay, not by your VNet.