[BUG] vnetSubnetID is not returned for kubenet networking plugin

[t-bzhan]

Describe the bug Per the instructions in the AKS creation blade, AKS will create a new VNet underlyingly using default values. However the created VNet Subnet Id is not available in all kinds of tools (Azure PowerShell, CLI etc.), that brings a lot of inconveniences. In our scenario, we need the VNet Subnet Id to enable network isolation for Cosmos DB, for the time being, there is no programming friendly way to obtain the VNet Subnet Id.

To Reproduce Steps to reproduce the behavior:

1. Create a new AKS cluster with kubenet networking plugin
2. Run az aks nodepool list --cluster-name cdnrpdfakswus2 -g cdnrp-df-wus2, the "vnetSubnetId" property is returned as null

Expected behavior The underlyingly used VNet Subnet should be returned to keep consistent with Azure CNI plugin.

Screenshots N/A.

Environment (please complete the following information):

• CLI Version [2.35.0]

Additional context N/A.

[ghost]

Action required from @Azure/aks-pm

[ghost]

Issue needing attention of @Azure/aks-leads

[ghost]

Issue needing attention of @Azure/aks-leads

[EugenFo]

We have the same problem with terraform. The returned vnetSubnetId is not null but an empty string instead, but that's probably terraform doing conversions from null to empty strings. We are also using the kubenet network plugin.

[paulgmiller]

This is currently intentional if you have a managed vnet rather than a byo vnet we hide vnet we make in your node resource group since its managed and our we don't believe it should be mutated.

[ghost]

Action required from @Azure/aks-pm

[ghost]

Issue needing attention of @Azure/aks-leads

[ghost]

Issue needing attention of @Azure/aks-leads

[ghost]

Issue needing attention of @Azure/aks-leads

[ghost]

Issue needing attention of @Azure/aks-leads

[ghost]

Issue needing attention of @Azure/aks-leads

[ghost]

Issue needing attention of @Azure/aks-leads

[ghost]

Issue needing attention of @Azure/aks-leads

[ghost]

Issue needing attention of @Azure/aks-leads

[ghost]

Issue needing attention of @Azure/aks-leads

[ghost]

Issue needing attention of @Azure/aks-leads

[ghost]

Issue needing attention of @Azure/aks-leads

[ghost]

Issue needing attention of @Azure/aks-leads

[ghost]

Issue needing attention of @Azure/aks-leads

[ghost]

Issue needing attention of @Azure/aks-leads

[ghost]

Issue needing attention of @Azure/aks-leads

[ghost]

Issue needing attention of @Azure/aks-leads

[ghost]

Issue needing attention of @Azure/aks-leads

[microsoft-github-policy-service[bot]]

Issue needing attention of @Azure/aks-leads

[Arkessler]

@paulgmiller @Azure/aks-leads Any updates on the thinking around this?

This has been a frustration for my team as well, and runs counter to how auto-generated resources act in competing cloud providers. If it's at all helpful, I'd like to describe two use cases where we've needed this value.

We deploy everything through Terraform. Terraform relies on modularity to link together resources. It's extremely typical to use the output value from one resource to deploy another.

Use-case 1: Running a Postgres instance in the same subnet as the cluster. For a while, we needed a postgres instance for our cluster, but wanted it to be as secure as possible. We didn't want to publicly expose it, and wanted to restrict access to just the AKS nodes. We decided to run it in the same vnet created by the AKS cluster, only to learn there was no way to do so without the subnet/vnet ID.

Use-case 2: I am currently looking to define network security groups for the auto-generated AKS subnets in order to lock down access further. As far as I am aware, this is not currently possible through the Terraform Kubernetes cluster resource directly. That wouldn't normally be an issue, I'd just define a subnet_network_security_group_association between a newly created security group and the auto-generated vnet. Unfortunately, there is no good programmatic way to do this without the vnet id (apart from some rather shaky local-exec commands).

In both of these cases we weren't looking to mutate the underlying vnet, merely to use it or link it to other resources. Unless the roadmap includes plans to support every possible usage of a subnet, as well as the ability to fully customize security groups, through the kubernetes_cluster resource, it seems, respectfully, a bit short-sighted to hide the value from customers.

For reference, here's an Issue of someone looking for similar behavior in the Terraform provider, only to be told it's impossible until the API exposes the information: https://github.com/hashicorp/terraform-provider-azurerm/issues/8220

[microsoft-github-policy-service[bot]]

Issue needing attention of @Azure/aks-leads

[microsoft-github-policy-service[bot]]

Issue needing attention of @Azure/aks-leads

[microsoft-github-policy-service[bot]]

Issue needing attention of @Azure/aks-leads

[microsoft-github-policy-service[bot]]

Issue needing attention of @Azure/aks-leads

[microsoft-github-policy-service[bot]]

Issue needing attention of @Azure/aks-leads

[microsoft-github-policy-service[bot]]

Issue needing attention of @Azure/aks-leads

[microsoft-github-policy-service[bot]]

Issue needing attention of @Azure/aks-leads

[microsoft-github-policy-service[bot]]

Issue needing attention of @Azure/aks-leads

[microsoft-github-policy-service[bot]]

Issue needing attention of @Azure/aks-leads

[microsoft-github-policy-service[bot]]

Issue needing attention of @Azure/aks-leads

[microsoft-github-policy-service[bot]]

Issue needing attention of @Azure/aks-leads

[microsoft-github-policy-service[bot]]

Issue needing attention of @Azure/aks-leads

[microsoft-github-policy-service[bot]]

Issue needing attention of @Azure/aks-leads