Merge branch 'main' of https://github.com/MicrosoftDocs/azure-docs-pr into tamram23-0316

Author: tamram

articles/active-directory/conditional-access/location-condition.md

@@ -1,12 +1,12 @@
 ---
-title: Location condition in Azure Active Directory Conditional Access
-description: Learn about creating location-based Conditional Access policies using Azure AD.
+title: Using networks and countries in Azure Active Directory
+description: Use GPS locations and public IPv4 and IPv6 networks in Conditional Access policy to make access decisions.
 
 services: active-directory
 ms.service: active-directory
 ms.subservice: conditional-access
 ms.topic: conceptual
-ms.date: 02/23/2023
+ms.date: 03/17/2023
 
 ms.author: joflore
 author: MicrosoftGuyJFlo
@@ -27,10 +27,13 @@ Conditional Access policies are at their most basic an if-then statement combini
 Organizations can use this location for common tasks like: 
 
 - Requiring multifactor authentication for users accessing a service when they're off the corporate network.
-- Blocking access for users accessing a service from specific countries or regions.
+- Blocking access for users accessing a service from specific countries or regions your organization never operates from.
 
 The location found using the public IP address a client provides to Azure Active Directory or GPS coordinates provided by the Microsoft Authenticator app. Conditional Access policies by default apply to all IPv4 and IPv6 addresses. For more information about IPv6 support, see the article [IPv6 support in Azure Active Directory](/troubleshoot/azure/active-directory/azure-ad-ipv6-support).
 
+> [!TIP]
+> Conditional Access policies are enforced after first-factor authentication is completed. Conditional Access isn't intended to be an organization's first line of defense for scenarios like denial-of-service (DoS) attacks, but it can use signals from these events to determine access.
+
 ## Named locations
 
 Locations exist in the Azure portal under **Azure Active Directory** > **Security** > **Conditional Access** > **Named locations**. These named network locations may include locations like an organization's headquarters network ranges, VPN network ranges, or ranges that you wish to block. Named locations are defined by IPv4 and IPv6 address ranges or by countries/regions. 
@@ -81,9 +84,7 @@ If you select **Determine location by IP address**, the system collects the IP a
 
 If you select **Determine location by GPS coordinates**, the user needs to have the Microsoft Authenticator app installed on their mobile device. Every hour, the system contacts the user’s Microsoft Authenticator app to collect the GPS location of the user’s mobile device.
 
-The first time the user must share their location from the Microsoft Authenticator app, the user receives a notification in the app. The user needs to open the app and grant location permissions.
-
-Every hour the user is accessing resources covered by the policy they need to approve a push notification from the app.
+The first time the user must share their location from the Microsoft Authenticator app, the user receives a notification in the app. The user needs to open the app and grant location permissions. Every hour the user is accessing resources covered by the policy they need to approve a push notification from the app.
 
 Every time the user shares their GPS location, the app does jailbreak detection (Using the same logic as the Intune MAM SDK). If the device is jailbroken, the location isn't considered valid, and the user isn't granted access. 
 
@@ -144,6 +145,12 @@ You can also find the client IP by clicking a row in the report, and then going
 
 ## What you should know
 
+### Cloud proxies and VPNs
+
+When you use a cloud hosted proxy or VPN solution, the IP address Azure AD uses while evaluating a policy is the IP address of the proxy. The X-Forwarded-For (XFF) header that contains the user’s public IP address isn't used because there's no validation that it comes from a trusted source, so would present a method for faking an IP address.
+
+When a cloud proxy is in place, a policy that requires a [hybrid Azure AD joined or compliant device](howto-conditional-access-policy-compliant-device.md#create-a-conditional-access-policy) can be easier to manage. Keeping a list of IP addresses used by your cloud hosted proxy or VPN solution up to date can be nearly impossible.
+
 ### When is a location evaluated?
 
 Conditional Access policies are evaluated when:
@@ -159,15 +166,23 @@ By default, Azure AD issues a token on an hourly basis. After users move off the
 
 The IP address used in policy evaluation is the public IPv4 or IPv6 address of the user. For devices on a private network, this IP address isn't the client IP of the user’s device on the intranet, it's the address used by the network to connect to the public internet.
 
-### Bulk uploading and downloading of named locations
+### When you might block locations?
 
-When you create or update named locations, for bulk updates, you can upload or download a CSV file with the IP ranges. An upload replaces the IP ranges in the list with those ranges from the file. Each row of the file contains one IP Address range in CIDR format.
+A policy that uses the location condition to block access is considered restrictive, and should be done with care after thorough testing. Some instances of using the location condition to block authentication may include:
 
-### Cloud proxies and VPNs
+- Blocking countries where your organization never does business.
+- Blocking specific IP ranges like:
+   - Known malicious IPs before a firewall policy can be changed.
+   - For highly sensitive or privileged actions and cloud applications.
+   - Based on user specific IP range like access to accounting or payroll applications.
 
-When you use a cloud hosted proxy or VPN solution, the IP address Azure AD uses while evaluating a policy is the IP address of the proxy. The X-Forwarded-For (XFF) header that contains the user’s public IP address isn't used because there's no validation that it comes from a trusted source, so would present a method for faking an IP address.
+### User exclusions
+
+[!INCLUDE [active-directory-policy-exclusions](../../../includes/active-directory-policy-exclude-user.md)]
 
-When a cloud proxy is in place, a policy that requires a hybrid Azure AD joined device can be used, or the inside corpnet claim from AD FS.
+### Bulk uploading and downloading of named locations
+
+When you create or update named locations, for bulk updates, you can upload or download a CSV file with the IP ranges. An upload replaces the IP ranges in the list with those ranges from the file. Each row of the file contains one IP Address range in CIDR format.
 
 ### API support and PowerShell
 

articles/aks/azure-cni-overlay.md

@@ -6,7 +6,7 @@ ms.author: allensu
 ms.subservice: aks-networking
 ms.topic: how-to
 ms.custom: references_regions
-ms.date: 03/09/2023
+ms.date: 03/21/2023
 ---
 
 # Configure Azure CNI Overlay networking in Azure Kubernetes Service (AKS)
@@ -43,27 +43,27 @@ Like Azure CNI Overlay, Kubenet assigns IP addresses to pods from an address spa
 
 ## IP address planning
 
-* **Cluster Nodes**: Cluster nodes go into a subnet in your VNet, so verify you have a subnet large enough to account for future scale. A simple `/24` subnet can host up to 251 nodes (the first three IP addresses in a subnet are reserved for management operations).
+- **Cluster Nodes**: Cluster nodes go into a subnet in your VNet, so verify you have a subnet large enough to account for future scale. A simple `/24` subnet can host up to 251 nodes (the first three IP addresses in a subnet are reserved for management operations).
 
-* **Pods**: The overlay solution assigns a `/24` address space for pods on every node from the private CIDR that you specify during cluster creation. The `/24` size is fixed and can't be increased or decreased. You can run up to 250 pods on a node. When planning the pod address space, ensure that the private CIDR is large enough to provide `/24` address spaces for new nodes to support future cluster expansion.
+- **Pods**: The overlay solution assigns a `/24` address space for pods on every node from the private CIDR that you specify during cluster creation. The `/24` size is fixed and can't be increased or decreased. You can run up to 250 pods on a node. When planning the pod address space, ensure that the private CIDR is large enough to provide `/24` address spaces for new nodes to support future cluster expansion.
 
 The following are additional factors to consider when planning pods IP address space:
 
-   * Pod CIDR space must not overlap with the cluster subnet range.
-   * Pod CIDR space must not overlap with IP ranges used in on-premises networks and peered networks.
-   * The same pod CIDR space can be used on multiple independent AKS clusters in the same VNet.
+   - Pod CIDR space must not overlap with the cluster subnet range.
+   - Pod CIDR space must not overlap with IP ranges used in on-premises networks and peered networks.
+   - The same pod CIDR space can be used on multiple independent AKS clusters in the same VNet.
 
-* **Kubernetes service address range**: The size of the service address CIDR depends on the number of cluster services you plan to create. It must be smaller than `/12`. This range should also not overlap with the pod CIDR range, cluster subnet range, and IP range used in peered VNets and on-premises networks.
+- **Kubernetes service address range**: The size of the service address CIDR depends on the number of cluster services you plan to create. It must be smaller than `/12`. This range should also not overlap with the pod CIDR range, cluster subnet range, and IP range used in peered VNets and on-premises networks.
 
-* **Kubernetes DNS service IP address**: This is an IP address within the Kubernetes service address range that's used by cluster service discovery. Don't use the first IP address in your address range, as this address is used for the `kubernetes.default.svc.cluster.local` address.
+- **Kubernetes DNS service IP address**: This is an IP address within the Kubernetes service address range that's used by cluster service discovery. Don't use the first IP address in your address range, as this address is used for the `kubernetes.default.svc.cluster.local` address.
 
 ## Network security groups
 
 Pod to pod traffic with Azure CNI Overlay is not encapsulated and subnet [network security group][nsg] rules are applied. If the subnet NSG contains deny rules that would impact the pod CIDR traffic, make sure the following rules are in place to ensure proper cluster functionality (in addition to all [AKS egress requirements][aks-egress]):
 
-* Traffic from the node CIDR to the node CIDR on all ports and protocols
-* Traffic from the node CIDR to the pod CIDR on all ports and protocols (required for service traffic routing)
-* Traffic from the pod CIDR to the pod CIDR on all ports and protocols (required for pod to pod and pod to service traffic, including DNS)
+- Traffic from the node CIDR to the node CIDR on all ports and protocols
+- Traffic from the node CIDR to the pod CIDR on all ports and protocols (required for service traffic routing)
+- Traffic from the pod CIDR to the pod CIDR on all ports and protocols (required for pod to pod and pod to service traffic, including DNS)
 
 Traffic from a pod to any destination outside of the pod CIDR block will utilize SNAT to set the source IP to the IP of the node where the pod is running.
 
@@ -79,23 +79,24 @@ Azure CNI offers two IP addressing options for pods - the traditional configurat
 
 Use overlay networking when:
 
-* You would like to scale to a large number of pods, but have limited IP address space in your VNet.
-* Most of the pod communication is within the cluster.
-* You don't need advanced AKS features, such as virtual nodes.
+- You would like to scale to a large number of pods, but have limited IP address space in your VNet.
+- Most of the pod communication is within the cluster.
+- You don't need advanced AKS features, such as virtual nodes.
 
 Use the traditional VNet option when:
 
-* You have available IP address space.
-* Most of the pod communication is to resources outside of the cluster.
-* Resources outside the cluster need to reach pods directly.
-* You need AKS advanced features, such as virtual nodes.
+- You have available IP address space.
+- Most of the pod communication is to resources outside of the cluster.
+- Resources outside the cluster need to reach pods directly.
+- You need AKS advanced features, such as virtual nodes.
 
 ## Limitations with Azure CNI Overlay
 
 Azure CNI Overlay has the following limitations:
 
-* You can't use Application Gateway as an Ingress Controller (AGIC) for an overlay cluster.
-* Windows Server 2019 node pools are not supported for overlay.
+- You can't use Application Gateway as an Ingress Controller (AGIC) for an overlay cluster.
+- Windows Server 2019 node pools are not supported for overlay.
+- Traffic from host network pods is not able to reach Windows overlay pods.
 
 ## Install the aks-preview Azure CLI extension
 
@@ -145,6 +146,27 @@ location="westcentralus"
 az aks create -n $clusterName -g $resourceGroup --location $location --network-plugin azure --network-plugin-mode overlay --pod-cidr 192.168.0.0/16
 ```
 
+## Upgrade an existing cluster to CNI Overlay
+
+You can update an existing Azure CNI cluster to Overlay if the cluster meets certain criteria. A cluster must:
+
+- be on Kubernetes version 1.22+
+- **not** be using the dynamic pod IP allocation feature
+- **not** have network policies enabled
+- **not** be using any Windows node pools with docker as the container runtime
+
+The upgrade process will trigger each node pool to be re-imaged simultaneously (i.e. upgrading each node pool separately to overlay is not supported). Any disruptions to cluster networking will be similar to a node image upgrade or Kubernetes version upgrade where each node in a node pool is re-imaged.
+
+> [!WARNING] 
+> Due to the limitation around Windows overlay pods incorrectly SNATing packets from host network pods, this has a more detrimental effect for clusters upgrading to overlay.
+
+While nodes are being upgraded to use the CNI Overlay feature, pods that are on nodes which haven't been upgraded yet will not be able to communicate with pods on Windows nodes that have been upgraded to Overlay. In other words, overlay Windows pods will not be able to reply to any traffic from pods still running with an IP from the node subnet.
+
+This network disruption will only occur during the upgrade. Once the migration to overlay has completed for all node pools, all overlay pods will be able to communicate successfully with the Windows pods.
+
+> [!NOTE]
+> The upgrade completion doesn't change the existing limitation that host network pods **cannot** communicate with Windows overlay pods.
+
 ## Next steps
 
 To learn how to utilize AKS with your own Container Network Interface (CNI) plugin, see [Bring your own Container Network Interface (CNI) plugin](use-byo-cni.md).