Merge pull request #202906 from CocoWang-wql/patch-5

Update limit-egress-traffic.md

Author: PRMerger5

articles/aks/limit-egress-traffic.md

@@ -4,7 +4,7 @@ description: Learn what ports and addresses are required to control egress traff
 services: container-service
 ms.topic: article
 ms.author: jpalma
-ms.date: 06/15/2022
+ms.date: 06/27/2022
 author: palma21
 
 #Customer intent: As an cluster operator, I want to restrict egress traffic for nodes to only access defined ports and addresses and improve cluster security.
@@ -442,40 +442,7 @@ Now an AKS cluster can be deployed into the existing virtual network. We'll also
 
 ![aks-deploy](media/limit-egress-traffic/aks-udr-fw.png)
 
-### Create a service principal with access to provision inside the existing virtual network
-
-A cluster identity (managed identity or service principal) is used by AKS to create cluster resources. A service principal that is passed at create time is used to create underlying AKS resources such as Storage resources, IPs, and Load Balancers used by AKS (you may also use a [managed identity](use-managed-identity.md) instead). If not granted the appropriate permissions below, you won't be able to provision the AKS Cluster.
-
-```azurecli
-# Create SP and Assign Permission to Virtual Network
-
-az ad sp create-for-rbac -n "${PREFIX}sp"
-```
-
-Now replace the `APPID` and `PASSWORD` below with the service principal appid and service principal password autogenerated by the previous command output. We'll reference the VNET resource ID to grant the permissions to the service principal so AKS can deploy resources into it.
-
-```azurecli
-APPID="<SERVICE_PRINCIPAL_APPID_GOES_HERE>"
-PASSWORD="<SERVICEPRINCIPAL_PASSWORD_GOES_HERE>"
-VNETID=$(az network vnet show -g $RG --name $VNET_NAME --query id -o tsv)
-
-# Assign SP Permission to VNET
-
-az role assignment create --assignee $APPID --scope $VNETID --role "Network Contributor"
-```
-
-You can check the detailed permissions that are required [here](kubernetes-service-principal.md#delegate-access-to-other-azure-resources).
-
-> [!NOTE]
-> If you're using the kubenet network plugin, you'll need to give the AKS service principal or managed identity permissions to the pre-created route table, since kubenet requires a route table to add neccesary routing rules.
-> ```azurecli-interactive
-> RTID=$(az network route-table show -g $RG -n $FWROUTE_TABLE_NAME --query id -o tsv)
-> az role assignment create --assignee $APPID --scope $RTID --role "Network Contributor"
-> ```
-
-### Deploy AKS
-
-Finally, the AKS cluster can be deployed into the existing subnet we've dedicated for the cluster. The target subnet to be deployed into is defined with the environment variable, `$SUBNETID`. We didn't define the `$SUBNETID` variable in the previous steps. To set the value for the subnet ID, you can use the following command:
+The target subnet to be deployed into is defined with the environment variable, `$SUBNETID`. We didn't define the `$SUBNETID` variable in the previous steps. To set the value for the subnet ID, you can use the following command:
 
 ```azurecli
 SUBNETID=$(az network vnet subnet show -g $RG --vnet-name $VNET_NAME --name $AKSSUBNET_NAME --query id -o tsv)
@@ -493,18 +460,19 @@ You'll define the outbound type to use the UDR that already exists on the subnet
 
 ```azurecli
 az aks create -g $RG -n $AKSNAME -l $LOC \
-  --node-count 3 --generate-ssh-keys \
+  --node-count 3 \
   --network-plugin $PLUGIN \
   --outbound-type userDefinedRouting \
-  --service-cidr 10.41.0.0/16 \
-  --dns-service-ip 10.41.0.10 \
-  --docker-bridge-address 172.17.0.1/16 \
   --vnet-subnet-id $SUBNETID \
-  --service-principal $APPID \
-  --client-secret $PASSWORD \
   --api-server-authorized-ip-ranges $FWPUBLIC_IP
 ```
 
+> [!NOTE]
+> For creating and using your own VNet and route table where the resources are outside of the worker node resource group, the CLI will add the role assignment automatically. If you are using an ARM template or other client, you need to use the Principal ID of the cluster managed identity to perform a [role assignment.][add role to identity]
+> 
+> If you are not using the CLI but using your own VNet or route table which are outside of the worker node resource group, it's recommended to use [user-assigned control plane identity][Bring your own control plane managed identity]. For system-assigned control plane identity, we cannot get the identity ID before creating cluster, which causes delay for role assignment to take effect.
+
+
 ### Enable developer access to the API server
 
 If you used authorized IP ranges for the cluster on the previous step, you must add your developer tooling IP addresses to the AKS cluster list of approved IP ranges in order to access the API server from there. Another option is to configure a jumpbox with the needed tooling inside a separate subnet in the Firewall's virtual network.
@@ -827,3 +795,5 @@ If you want to restrict how pods communicate between themselves and East-West tr
 [aks-support-policies]: support-policies.md
 [aks-faq]: faq.md
 [aks-private-clusters]: private-clusters.md
+[add role to identity]: use-managed-identity.md#add-role-assignment-for-control-plane-identity
+[Bring your own control plane managed identity]: use-managed-identity.md#bring-your-own-control-plane-managed-identity