Secure AKS API from Public Internet
Managed K8s in Azure makes the AKS API publically accessible via an Internet endpoint.
This Master node access is separate from the Agent nodes we stand up inside a VNet and can protect with interior private IPs and NSGs.
While access to the AKS-API is be protected using Azure DDOS, and integration to AAD and RBAC for user access, some customer security organizations demand either IP whitelisting on it, or some type of if firewalling to limit access to it to only their company. VNet Service Endpoint as another option although not certain can can work. But that kind of protection is sought.
William Hearn commented
For a government department it is also crucial for us to have a private IP address and to be deployed in our custom vnet all secured by Fortigate. At the moment this is the only reason we can go to AKS and stick with AKS Engine which supports this scenario.
Love the current work being done but super hoping can look at this? Or should it be a new Idea that is voted on?
Yes Agreed with @Traiano. The API endpoint should have a private IP address and to be deployed in Customer Subnet to put whatever security needed by customer. Adding firewall is another route, but is will increase the cost of usage. Rather than this approach, even if master can be a paid service and available on private IP range similar to AWS EKS. It will help.
It will not be sufficient to have a whitelisting mechanism for the public API endpoint.
What is required is a private address for the API endpoint that lives in the same subnet as the aKS cluster nodes and allows fully secure traffic for applications in the AKS subnet.
Marek Roszko commented
The expectation to use the Azure Firewall is absolutely ludicrous. It's $900/month just for a firewall deployment.
Abhishek Kumar Gupta commented
Thanks @Marek Grabarz , I hope soon the same functionality should be available via standard ARM Template.
Marek Grabarz commented
Please take a look into az cli aks extension: https://github.com/Azure/azure-cli-extensions/tree/master/src/aks-preview
Abhishek Kumar Gupta commented
Any update on this?
Are there any updates on this yet?
Hi AKS Team. It would be most helpful to have some additional feedback on this improvement request. I'm aware of a number of companies unable to switch to AKS due to the inability to secure the AKS API.
Could you perhaps indicate an expected time frame for this work as well as your current thoughts regarding the implementation approach, IP whitelisting?, VNet Endpoint?. This would help others plan future projects around your plans for this feature.
Bas Hermens commented
Are there any updates on the this matter. We do not feel comfy with exposing our k8s API, with so much power, to the www domain.
We rather approach it from within a vnet and/or a so called stepping-stone machine.
Is it possible to just use AKS API within Vnet . I do not want to expose to internet . Enterprise users connected to Azure subscription using VPN or Express route are only allowed to connect to AKS API end point. Exposing AKS end point to public is risky and more critical applications can't be deployed. AKS cluster API end point can be deployed within Internal Load balancer. similar to KOPS setup , where user can choose API to be expose to internal load balancer or external LB to Internet.
Please post updates once this is developed as currently it is a security risk and we cannot move to production without it being implemented
David Martinez commented
Any update on this? We can't go to production without it.
We need updates on that! we cant go to production without protecting the API, otherwise we will try another provider.
Steve DiStefano commented
I just saw this on 1/28/2019, but it is just the announcement. Is there more detail on implementation? https://azure.microsoft.com/en-us/updates/aks-private-cluster/
Mark Dommisse commented
Our customers are not happy with the current solutions. Is there an ETA for the restriction of IP ranges? VNet Service Endpoint is the preferred option.
Timothy Farkas commented
This is required especially in light of the latest kubernetes vulnerability