Restrict AKS API Server with Authorized IP Ranges (2026)

AKS API Server, when exposed publicly, is a massive attack surface. Restricting access to only known IPs is a critical security measure.

Here’s how to do it:

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --api-server-authorized-ip-ranges 1.2.3.4/32 5.6.7.8/29

This command updates your AKS cluster to only allow API server requests originating from the specified IP address ranges. The /32 CIDR denotes a single IP address, while /29 represents a subnet.

Let’s break down what’s happening and why it’s important.

The Problem: An Open Door

By default, your AKS API server endpoint is accessible from anywhere on the internet. While authentication (like Azure AD or service principal) protects who can access it, it doesn’t restrict where they can access it from. This means an attacker could potentially try to brute-force credentials or exploit vulnerabilities from any IP address.

The Solution: Network Whitelisting

The --api-server-authorized-ip-ranges parameter allows you to define a whitelist of IP addresses or CIDR blocks that are permitted to communicate with the Kubernetes API server. All other traffic will be dropped at the network level before it even reaches the API server for authentication.

How it Works Under the Hood

When you apply this setting, Azure creates a Network Security Group (NSG) rule associated with the API server’s load balancer. This rule explicitly permits inbound traffic on the API server’s port (usually 443) only from the IP addresses you’ve specified. Any traffic attempting to reach the API server from an IP not in this list will be silently discarded by the NSG.

Practical Implementation

1. Identify Your IPs: Determine the static public IP addresses or IP ranges that your users or CI/CD systems will be using to access the AKS cluster. This might include your office’s public IP, your VPN gateway IP, or the egress IPs of your CI/CD pipeline runners.
2. Construct the Command: Use the az aks update command as shown above.
   • --resource-group <your-aks-resource-group>: The name of the resource group containing your AKS cluster.
   • --name <your-aks-cluster-name>: The name of your AKS cluster.
   • --api-server-authorized-ip-ranges <ip-range1> <ip-range2> ...: A space-separated list of IP addresses or CIDR blocks. You can specify individual IPs (e.g., 203.0.113.5/32) or entire subnets (e.g., 192.168.1.0/24).
3. Apply the Change: Execute the command. The update process can take a few minutes.
4. Verification: After the update, try to access your API server from an IP not in the authorized list. You should receive a connection timed out or a similar network-level error, not an authentication error. Then, try from an authorized IP to confirm connectivity.

Important Considerations

• Dynamic IPs: If your access IPs are dynamic, this approach can become cumbersome. Consider using Azure Private Link for AKS, which provides a private endpoint for your API server, eliminating public exposure entirely.
• Service Principals/Managed Identities: This setting restricts network access. You still need proper authentication and authorization (RBAC) for users or service principals accessing the cluster.
• 0.0.0.0/0: If you specify 0.0.0.0/0, it effectively means "allow all IPs," which is the default and defeats the purpose of this restriction.

The Next Hurdle: Managing IP Changes

Once you’ve locked down your API server, the next challenge is managing the authorized IP ranges. If a user’s IP changes, or your CI/CD system’s egress IPs are updated, you’ll need to re-run the az aks update command. This can lead to accidental lockouts if not managed carefully.