Merge pull request #230057 from MicrosoftDocs/main

Publish to live, Thursday 4 AM PST, 3/9

Author: ttorble

.openpublishing.redirection.defender-for-cloud.json

@@ -787,7 +787,7 @@
         },
         {
             "source_path_from_root": "/articles/defender-for-cloud/os-coverage.md",
-            "redirect_url": "/azure/defender-for-cloud/monitoring-components",
+            "redirect_url": "/azure/defender-for-cloud/support-matrix-defender-for-cloud#supported-operating-systems",
             "redirect_document_id": false
         },
         {

articles/active-directory/hybrid/four-steps.md

@@ -52,6 +52,7 @@ To grant tenant-wide admin consent to an app listed in **Enterprise applications
 1. Select the application to which you want to grant tenant-wide admin consent, and then select **Permissions**.
    :::image type="content" source="media/grant-tenant-wide-admin-consent/grant-tenant-wide-admin-consent.png" alt-text="Screenshot shows how to grant tenant-wide admin consent.":::
 
+1. Add the redirect **URI** (https://entra.microsoft.com/TokenAuthorize) as permitted redirect **URI** to the app.
 1. Carefully review the permissions that the application requires. If you agree with the permissions the application requires, select **Grant admin consent**.
 
 ## Grant admin consent in App registrations

articles/active-directory/manage-apps/grant-admin-consent.md

@@ -1,9 +1,8 @@
 ---
-title: Best practices for AKS business continuity and disaster recovery
-description: Learn a cluster operator's best practices to achieve maximum uptime for your applications, providing high availability and preparing for disaster recovery in Azure Kubernetes Service (AKS).
+title: Best practices for business continuity and disaster recovery in Azure Kubernetes Service (AKS)
+description: Best practices for a cluster operator to achieve maximum uptime for your applications and to provide high availability and prepare for disaster recovery in Azure Kubernetes Service (AKS).
 ms.topic: conceptual
-ms.date: 03/11/2021
-ms.author: thfalgou
+ms.date: 03/08/2023
 ms.custom: fasttrack-edit
 #Customer intent: As an AKS cluster operator, I want to plan for business continuity or disaster recovery to help protect my cluster from region problems.
 ---
@@ -15,8 +14,9 @@ As you manage clusters in Azure Kubernetes Service (AKS), application uptime bec
 This article focuses on how to plan for business continuity and disaster recovery in AKS. You learn how to:
 
 > [!div class="checklist"]
+
 > * Plan for AKS clusters in multiple regions.
-> * Route traffic across multiple clusters by using Azure Traffic Manager.
+> * Route traffic across multiple clusters using Azure Traffic Manager.
 > * Use geo-replication for your container image registries.
 > * Plan for application state across multiple clusters.
 > * Replicate storage across multiple regions.
@@ -30,15 +30,17 @@ This article focuses on how to plan for business continuity and disaster recover
 An AKS cluster is deployed into a single region. To protect your system from region failure, deploy your application into multiple AKS clusters across different regions. When planning where to deploy your AKS cluster, consider:
 
 * [**AKS region availability**](./quotas-skus-regions.md#region-availability)
-    * Choose regions close to your users. 
+    * Choose regions close to your users.
     * AKS continually expands into new regions.
+
 * [**Azure paired regions**](../availability-zones/cross-region-replication-azure.md)
     * For your geographic area, choose two regions paired together.
-    * AKS platform updates (planned maintenance) are serialized with a delay of at least 24 hours between paired regions. 
-    * Recovery efforts for paired regions are prioritized where needed. 
+    * AKS platform updates (planned maintenance) are serialized with a delay of at least 24 hours between paired regions.
+    * Recovery efforts for paired regions are prioritized where needed.
+
 * **Service availability**
     * Decide whether your paired regions should be hot/hot, hot/warm, or hot/cold.
-    * Do you want to run both regions at the same time, with one region *ready* to start serving traffic? Or,
+    * Do you want to run both regions at the same time, with one region *ready* to start serving traffic? *or*
     * Do you want to give one region time to get ready to serve traffic?
 
 AKS region availability and paired regions are a joint consideration. Deploy your AKS clusters into paired regions designed to manage region disaster recovery together. For example, AKS is available in East US and West US. These regions are paired. Choose these two regions when you're creating an AKS BC/DR strategy.
@@ -66,11 +68,12 @@ For information on how to set up endpoints and routing, see [Configure priority
 ### Application routing with Azure Front Door Service
 
 Using split TCP-based anycast protocol, [Azure Front Door Service](../frontdoor/front-door-overview.md) promptly connects your end users to the nearest Front Door POP (Point of Presence). More features of Azure Front Door Service:
+
 * TLS termination
 * Custom domain
 * Web application firewall
 * URL Rewrite
-* Session affinity 
+* Session affinity
 
 Review the needs of your application traffic to understand which solution is the most suitable.
 
@@ -83,18 +86,16 @@ Before peering virtual networks with running AKS clusters, use the standard Load
 ## Enable geo-replication for container images
 
 > **Best practice**
-> 
+>
 > Store your container images in Azure Container Registry and geo-replicate the registry to each AKS region.
 
-To deploy and run your applications in AKS, you need a way to store and pull the container images. Container Registry integrates with AKS, so it can securely store your container images or Helm charts. Container Registry supports multimaster geo-replication to automatically replicate your images to Azure regions around the world. 
+To deploy and run your applications in AKS, you need a way to store and pull the container images. Container Registry integrates with AKS, so it can securely store your container images or Helm charts. Container Registry supports multimaster geo-replication to automatically replicate your images to Azure regions around the world.
 
-To improve performance and availability:
-1. Use Container Registry geo-replication to create a registry in each region where you have an AKS cluster. 
-1. Each AKS cluster then pulls container images from the local container registry in the same region:
+To improve performance and availability, use Container Registry geo-replication to create a registry in each region where you have an AKS cluster.Each AKS cluster will then pull container images from the local container registry in the same region.
 
 ![Container Registry geo-replication for container images](media/operator-best-practices-bc-dr/acr-geo-replication.png)
 
-When you use Container Registry geo-replication to pull images from the same region, the results are:
+Using Container Registry geo-replication to pull images from the same region has the following benefits: 
 
 * **Faster**: Pull images from high-speed, low-latency network connections within the same Azure region.
 * **More reliable**: If a region is unavailable, your AKS cluster pulls the images from an available container registry.
@@ -105,14 +106,15 @@ Geo-replication is a *Premium* SKU container registry feature. For information o
 ## Remove service state from inside containers
 
 > **Best practice**
-> 
+>
 > Avoid storing service state inside the container. Instead, use an Azure platform as a service (PaaS) that supports multi-region replication.
 
 *Service state* refers to the in-memory or on-disk data required by a service to function. State includes the data structures and member variables that the service reads and writes. Depending on how the service is architected, the state might also include files or other resources stored on the disk. For example, the state might include the files a database uses to store data and transaction logs.
 
 State can be either externalized or co-located with the code that manipulates the state. Typically, you externalize state by using a database or other data store that runs on different machines over the network or that runs out of process on the same machine.
 
 Containers and microservices are most resilient when the processes that run inside them don't retain state. Since applications almost always contain some state, use a PaaS solution, such as:
+
 * Azure Cosmos DB
 * Azure Database for PostgreSQL
 * Azure Database for MySQL
@@ -139,6 +141,7 @@ Your applications might use Azure Storage for their data. If so, your applicatio
 Your applications might require persistent storage even after a pod is deleted. In Kubernetes, you can use persistent volumes to persist data storage. Persistent volumes are mounted to a node VM and then exposed to the pods. Persistent volumes follow pods even if the pods are moved to a different node inside the same cluster.
 
 The replication strategy you use depends on your storage solution. The following common storage solutions provide their own guidance about disaster recovery and replication:
+
 * [Gluster](https://docs.gluster.org/en/latest/Administrator-Guide/Geo-Replication/)
 * [Ceph](https://docs.ceph.com/docs/master/cephfs/disaster-recovery/)
 * [Rook](https://rook.io/docs/rook/v1.2/ceph-disaster-recovery.html)

articles/aks/operator-best-practices-multi-region.md

@@ -1,6 +1,6 @@
 ---
 title: "Cluster extensions - Azure Arc-enabled Kubernetes"
-ms.date: 01/23/2023
+ms.date: 03/08/2023
 ms.topic: conceptual
 description: "This article provides a conceptual overview of the Azure Arc-enabled Kubernetes cluster extensions capability."
 ---
@@ -34,6 +34,9 @@ Both the `config-agent` and `extensions-manager` components running in the clust
 >
 > Protected configuration settings for an extension instance are stored for up to 48 hours in the Azure Arc-enabled Kubernetes services. As a result, if the cluster remains disconnected during the 48 hours after the extension resource was created on Azure, the extension changes from a `Pending` state to `Failed` state. To prevent this, we recommend bringing clusters online regularly.
 
+> [!IMPORTANT]
+> Currently, Azure Arc-enabled Kubernetes cluster extensions aren't supported on ARM64-based clusters. To [install and use cluster extensions](extensions.md), the cluster must have at least one node of operating system and architecture type `linux/amd64`.
+
 ## Extension scope
 
 Each extension type defines the scope at which they operate on the cluster. Extension installations on Arc-enabled Kubernetes clusters are either *cluster-scoped* or *namespace-scoped*.

articles/azure-arc/kubernetes/conceptual-extensions.md

@@ -1,7 +1,7 @@
 ---
 title: "Azure Arc-enabled Kubernetes cluster extensions"
 ms.custom: event-tier1-build-2022, ignite-2022
-ms.date: 01/23/2023
+ms.date: 03/08/2023
 ms.topic: how-to
 description: "Deploy and manage lifecycle of extensions on Azure Arc-enabled Kubernetes clusters."
 ---
@@ -39,7 +39,7 @@ Before you begin, read the [conceptual overview of Arc-enabled Kubernetes cluste
     az extension update --name k8s-extension
     ```
 
-* An existing Azure Arc-enabled Kubernetes connected cluster.
+* An existing Azure Arc-enabled Kubernetes connected cluster, with at least  one node of operating system and architecture type `linux/amd64`.
   * If you haven't connected a cluster yet, use our [quickstart](quickstart-connect-cluster.md).
   * [Upgrade your agents](agent-upgrade.md#manually-upgrade-agents) to the latest version.
 

articles/azure-arc/kubernetes/extensions.md

@@ -27,5 +27,6 @@ For a complete list of network requirements for Azure Arc features and Azure Arc
 
 ## Next steps
 
+- Learn about other [requirements for Arc-enabled Kubernetes](system-requirements.md).
 - Use our [quickstart](quickstart-connect-cluster.md) to connect your cluster.
 - Review [frequently asked questions](faq.md) about Arc-enabled Kubernetes.

articles/azure-arc/kubernetes/network-requirements.md

@@ -2,7 +2,7 @@
 title: "Quickstart: Connect an existing Kubernetes cluster to Azure Arc"
 description: In this quickstart, you learn how to connect an Azure Arc-enabled Kubernetes cluster.
 ms.topic: quickstart
-ms.date: 03/07/2023
+ms.date: 03/08/2023
 ms.custom: template-quickstart, mode-other, devx-track-azurecli, devx-track-azurepowershell
 ms.devlang: azurecli
 ---
@@ -20,20 +20,10 @@ In addition to the prerequisites below, be sure to meet all [network requirement
 ### [Azure CLI](#tab/azure-cli)
 
 * An Azure account with an active subscription. [Create an account for free](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).
-
 * A basic understanding of [Kubernetes core concepts](../../aks/concepts-clusters-workloads.md).
-
-* An identity (user or service principal) which can be used to [log in to Azure CLI](/cli/azure/authenticate-azure-cli) and connect your cluster to Azure Arc.
-
-  > [!IMPORTANT]
-  >
-  > * The identity must have 'Read' and 'Write' permissions on the Azure Arc-enabled Kubernetes resource type (`Microsoft.Kubernetes/connectedClusters`).
-  > * If connecting the cluster to an existing resource group (rather than a new one created by this identity), the identity must have 'Read' permission for that resource group.
-  > * The [Kubernetes Cluster - Azure Arc Onboarding built-in role](../../role-based-access-control/built-in-roles.md#kubernetes-cluster---azure-arc-onboarding) can be used for this identity. This role is useful for at-scale onboarding, as it has only the granular permissions required to connect clusters to Azure Arc, and doesn't have permission to update, delete, or modify any other clusters or other Azure resources.
-
-* [Install or upgrade Azure CLI](/cli/azure/install-azure-cli) to the latest version.
-
-* Install the latest version of **connectedk8s** Azure CLI extension:
+* An [identity (user or service principal)](system-requirements.md#azure-ad-identity-requirements) which can be used to [log in to Azure CLI](/cli/azure/authenticate-azure-cli) and connect your cluster to Azure Arc.
+* The latest version of [Azure CLI](/cli/azure/install-azure-cli).
+* The latest version of **connectedk8s** Azure CLI extension, installed by running the following command:
 
   ```azurecli
   az extension add --name connectedk8s
@@ -45,48 +35,34 @@ In addition to the prerequisites below, be sure to meet all [network requirement
   * Self-managed Kubernetes cluster using [Cluster API](https://cluster-api.sigs.k8s.io/user/quick-start.html)
 
     >[!NOTE]
-    > The cluster needs to have at least one node of operating system and architecture type `linux/amd64`. Clusters with only `linux/arm64` nodes aren't yet supported.
-
-* At least 850 MB free for the Arc agents that will be deployed on the cluster, and capacity to use approximately 7% of a single CPU. For a multi-node Kubernetes cluster environment,  pods can get scheduled on different nodes.
+    > The cluster needs to have at least one node of operating system and architecture type `linux/amd64` and/or `linux/arm64`. See [Cluster requirements](system-requirements.md#cluster-requirements) for more about ARM64 scenarios.
 
+* At least 850 MB free for the Arc agents that will be deployed on the cluster, and capacity to use approximately 7% of a single CPU.
 * A [kubeconfig file](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) and context pointing to your cluster.
-
 * Install [Helm 3](https://helm.sh/docs/intro/install). Ensure that the Helm 3 version is < 3.7.0.
 
 ### [Azure PowerShell](#tab/azure-powershell)
 
 * An Azure account with an active subscription. [Create an account for free](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).
-
 * A basic understanding of [Kubernetes core concepts](../../aks/concepts-clusters-workloads.md).
-
+* An [identity (user or service principal)](system-requirements.md#azure-ad-identity-requirements) which can be used to [log in to Azure PowerShell](/powershell/azure/authenticate-azureps)  and connect your cluster to Azure Arc.
 * [Azure PowerShell version 6.6.0 or later](/powershell/azure/install-az-ps)
-
-* Install the **Az.ConnectedKubernetes** PowerShell module:
+* The **Az.ConnectedKubernetes** PowerShell module, installed by running the following command:
 
     ```azurepowershell-interactive
     Install-Module -Name Az.ConnectedKubernetes
     ```
 
-* An identity (user or service principal) which can be used to [log in to Azure PowerShell](/powershell/azure/authenticate-azureps)  and connect your cluster to Azure Arc.
-
-  > [!IMPORTANT]
-  >
-  > * The identity must have 'Read' and 'Write' permissions on the Azure Arc-enabled Kubernetes resource type (`Microsoft.Kubernetes/connectedClusters`).
-  > * If connecting the cluster to an existing resource group (rather than a new one created by this identity), the identity must have 'Read' permission for that resource group.
-  > * The [Kubernetes Cluster - Azure Arc Onboarding built-in role](../../role-based-access-control/built-in-roles.md#kubernetes-cluster---azure-arc-onboarding) is useful for at-scale onboarding as it has the granular permissions required to only connect clusters to Azure Arc. This role doesn't have the permissions to update, delete, or modify any other clusters or other Azure resources.
-
 * An up-and-running Kubernetes cluster. If you don't have one, you can create a cluster using one of these options:
   * [Kubernetes in Docker (KIND)](https://kind.sigs.k8s.io/)
   * Create a Kubernetes cluster using Docker for [Mac](https://docs.docker.com/docker-for-mac/#kubernetes) or [Windows](https://docs.docker.com/docker-for-windows/#kubernetes)
   * Self-managed Kubernetes cluster using [Cluster API](https://cluster-api.sigs.k8s.io/user/quick-start.html)
 
     >[!NOTE]
-    > The cluster needs to have at least one node of operating system and architecture type `linux/amd64`. Clusters with only `linux/arm64` nodes aren't yet supported.
-
-* At least 850 MB free for the Arc agents that will be deployed on the cluster, and capacity to use approximately 7% of a single CPU. For a multi-node Kubernetes cluster environment,  pods can get scheduled on different nodes.
+    > The cluster needs to have at least one node of operating system and architecture type `linux/amd64` and/or `linux/arm64`. See [Cluster requirements](system-requirements.md#cluster-requirements) for more about ARM64 scenarios.
 
+* At least 850 MB free for the Arc agents that will be deployed on the cluster, and capacity to use approximately 7% of a single CPU.
 * A [kubeconfig file](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) and context pointing to your cluster.
-
 * Install [Helm 3](https://helm.sh/docs/intro/install). Ensure that the Helm 3 version is < 3.7.0.
 
 ---