search

Azure / AKS

Azure Kubernetes Service
https://azure.github.io/AKS/
1.97k stars 308 forks source link

[Feedback] AKS Automatic should not have api-server publicly exposed. #4562

Open weberri opened 1 month ago

weberri commented 1 month ago

Our company mandates that the api-server of a Kubernetes cluster may not be exposed publicly without any network access restrictions.

As it is set up now, "AKS Automatic" (preview) is exposing its api-server publicly without any network access restrictions imposed and also none can be imposed subsequently.

This means, as it is set up now, our company cannot use "AKS Automatic".

If you can, please consider while re-shaping this preview service, to allow for network access restrictions or preferably private access to "AKS Automatic" api-server.

chengliangli0918 commented 1 month ago

You can create private AKS Automatic cluster by az aks create -g myrg -n myprivateauto --sku automatic --enable-private-cluster

weberri commented 3 weeks ago

Dear Cheng Liang Li,

I tried your suggestion, and it seems to result in a "not publicly connectable" URL to the API server of the resulting AKS Automatic cluster (of type myprivatea-#rg-name#-f60d25-4jjo92bp.hcp.#region#.azmk8s.io with public nslookup resolving to a 10.226.#.# address).

However I do not find the display in the Azure Portal particularly reassuring: Image which says: Public access to API server: Enabled Would it be possible to adapt this information and to include the appropriate instructions into the official documentation?

tspearconquest commented 3 weeks ago

Hi - fellow user here. The private API server requires additional preview APIs in AKS aside from those for AKS automatic. The additional preview APIs are not supported at this time by the Azure CLI, thus you would not be able to create it until the AKS API server vnet integration feature is promoted from preview to GA (expected currently in Q1 2025) and the azure CLI flag is added to support the then-GA feature.

Once that's done, you will additionally need some mechanism to connect to your API server and any services in the cluster privately; this will require a number of additional resources to be created. On the cheaper, smaller, less secure end, you can simply make a publicly exposed VM in the same vnet after the cluster is created, and ssh into that, install kubectl, and connect to the cluster. In the more expensive and more secure middle, you can setup a VPN between your on-prem and the azure virtual network and connect through the VPN to the private endpoint. On the premium/enterprise side, you can configure a central hub network with a firewall and vpn appliance, and a peering to your cluster's virtual network (hub-and-spoke networking) and configure routes to the cluster.

Most of this is far beyond what Microsoft likely has in mind as a potential scope for this preview service, just FYI.

microsoft-github-policy-service[bot] commented 5 days ago

This issue has been automatically marked as stale because it has not had any activity for 21 days. It will be closed if no further activity occurs within 7 days of this comment.