You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/aks/api-server-authorized-ip-ranges.md
+9-7Lines changed: 9 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -24,8 +24,10 @@ This article shows you how to use API server authorized IP address ranges, using
24
24
### Limitations
25
25
26
26
The API server Authorized IP ranges feature has the following limitations:
27
-
- On clusters created after API server authorized IP address ranges moved out of preview in October 2019, API server authorized IP address ranges are only supported on the *Standard* SKU load balancer. Existing clusters with the *Basic* SKU load balancer and API server authorized IP address ranges configured will continue work as is but cannot be migrated to a *Standard* SKU load balancer. Those existing clusters will also continue to work if their Kubernetes version or control plane are upgraded. API server authorized IP address ranges are not supported for private clusters.
28
-
- When using this feature with clusters that use [Public IP per Node](use-multiple-node-pools.md#assign-a-public-ip-per-node-for-your-node-pools), those node pools with public IP per node enabled must use public IP prefixes and those prefixes must be added as authorized ranges.
27
+
28
+
- On clusters created after API server authorized IP address ranges moved out of preview in October 2019, API server authorized IP address ranges are only supported on the *Standard* SKU load balancer. Existing clusters with the *Basic* SKU load balancer and API server authorized IP address ranges configured will continue work as is, but they cann't be migrated to a *Standard* SKU load balancer. Existing clusters will also continue to work if their Kubernetes version or control plane are upgraded.
29
+
- API server authorized IP address ranges aren't supported with private clusters.
30
+
- When using this feature with clusters that use [Public IP per Node](use-multiple-node-pools.md#assign-a-public-ip-per-node-for-your-node-pools), those node pools with public IP per node enabled must use public IP prefixes, and those prefixes must be added as authorized ranges.
29
31
30
32
## Overview of API server authorized IP ranges
31
33
@@ -66,7 +68,7 @@ az aks create \
66
68
67
69
### Specify the outbound IPs for the Standard SKU load balancer
68
70
69
-
When creating an AKS cluster, if you specify the outbound IP addresses or prefixes for the cluster, those addresses or prefixes are allowed as well. For example:
71
+
While creating an AKS cluster, if you specify the outbound IP addresses or prefixes for the cluster, they are allowed as well. For example:
70
72
71
73
```azurecli-interactive
72
74
az aks create \
@@ -146,11 +148,11 @@ The above operations of adding, updating, finding, and disabling authorized IP r
146
148
147
149
## How to find my IP to include in `--api-server-authorized-ip-ranges`?
148
150
149
-
You must add your development machines, tooling or automation IP addresses to the AKS cluster list of approved IP ranges in order to access the API server from there.
151
+
You must add your development machines, tooling, or automation IP addresses to the AKS cluster list of approved IP ranges to access the API server from there.
150
152
151
-
Another option is to configure a jumpbox with the necessary tooling inside a separate subnet in the firewall's virtual network. This assumes your environment has a firewall with the respective network, and you have added the firewall IPs to authorized ranges. Similarly, if you have forced tunneling from the AKS subnet to the firewall subnet, than having the jumpbox in the cluster subnet is also okay.
153
+
Another option is to configure a jumpbox with the necessary tooling inside a separate subnet in the firewall's virtual network. This assumes your environment has a firewall with the respective network, and you've added the firewall IPs to authorized ranges. Similarly, if you've forced tunneling from the AKS subnet to the firewall subnet, having the jumpbox in the cluster subnet is also okay.
152
154
153
-
Add another IP address to the approved ranges with the following command.
155
+
To add another IP address to the approved ranges, use the following commands.
154
156
155
157
```bash
156
158
# Retrieve your IP address
@@ -165,7 +167,7 @@ az aks update -g $RG -n $AKSNAME --api-server-authorized-ip-ranges $CURRENT_IP/3
165
167
> [!NOTE]
166
168
> The above example appends the API server authorized IP ranges on the cluster. To disable authorized IP ranges, use `az aks update` and specify an empty range "".
167
169
168
-
Another option is to use the command below on Windows systems to get the public IPv4 address, or you can follow the steps in [Find your IP address](https://support.microsoft.com/en-gb/help/4026518/windows-10-find-your-ip-address).
170
+
Another option is to use the following command on Windows systems to get the public IPv4 address, or you can follow the steps in [Find your IP address](https://support.microsoft.com/en-gb/help/4026518/windows-10-find-your-ip-address).
169
171
170
172
```azurepowershell-interactive
171
173
Invoke-RestMethod http://ipinfo.io/json | Select -exp ip
0 commit comments