How can we improve the Azure Kubernetes Service (AKS)?

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.

220 votes
Sign in
Sign in with: oidc
Signed in as (Sign out)

We’ll send you updates on this idea

Steve DiStefano shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Sign in with: oidc
Signed in as (Sign out)
  • Muthukumar commented  ·   ·  Flag as inappropriate

    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.

  • Traiano commented  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    The expectation to use the Azure Firewall is absolutely ludicrous. It's $900/month just for a firewall deployment.

  • JT commented  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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.

  • Sas01 commented  ·   ·  Flag as inappropriate

    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.

  • Amandeep commented  ·   ·  Flag as inappropriate

    Please post updates once this is developed as currently it is a security risk and we cannot move to production without it being implemented

  • Pau commented  ·   ·  Flag as inappropriate

    We need updates on that! we cant go to production without protecting the API, otherwise we will try another provider.

  • Mark Dommisse commented  ·   ·  Flag as inappropriate

    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.

← Previous 1

Feedback and Knowledge Base