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

Author: dlepow

.openpublishing.redirection.azure-monitor.json

@@ -420,6 +420,11 @@
             "source_path_from_root": "/articles/azure-monitor/insights/network-insights-overview.md" ,
             "redirect_url": "/azure/network-watcher/network-insights-overview",
             "redirect_document_id": false
+        },
+        {
+            "source_path_from_root": "/articles/azure-monitor/insights/key-vault-insights-overview.md" ,
+            "redirect_url": "/azure/key-vault/key-vault-insights-overview",
+            "redirect_document_id": false
         }
     ]
 }

CODEOWNERS

@@ -25,17 +25,17 @@ articles/advisor @rboucher
 articles/service-health @rboucher
 
 # Azure Synapse Analytics
-/articles/synapse-analytics/ @julieMSFT @ryanmajidi @saveenr 
-/articles/synapse-analytics/backuprestore/ @joannapea @julieMSFT
+/articles/synapse-analytics/ @SnehaGunda @WilliamDAssafMSFT @ryanmajidi @saveenr 
+/articles/synapse-analytics/backuprestore/ @joannapea @WilliamDAssafMSFT 
 /articles/synapse-analytics/catalog-governance/@djpmsft @chanuengg 
-/articles/synapse-analytics/ccid/ @liudan66 @julieMSFT
+/articles/synapse-analytics/ccid/ @liudan66
 /articles/synapse-analytics/data-integration/ @kromerm @jonburchel 
 /articles/synapse-analytics/machine-learning/ @garyericson @NelGson @midesa 
-/articles/synapse-analytics/metadata/@MikeRys @julieMSFT @jocaplan
-/articles/synapse-analytics/security/ @RonyMSFT  @nanditavalsan @meenalsri @julieMSFT
+/articles/synapse-analytics/metadata/@MikeRys @jocaplan
+/articles/synapse-analytics/security/ @RonyMSFT @meenalsri 
 /articles/synapse-analytics/spark/ @euangms @mlee3gsd @midesa 
-/articles/synapse-analytics/sql/ @filippopovic @azaricstefan @anumjs @WilliamDAssafMSFT @jovanpop-msft
-/articles/synapse-analytics/sql-data-warehouse/ @anumjs @ronortloff @julieMSFT
+/articles/synapse-analytics/sql/ @filippopovic @azaricstefan @WilliamDAssafMSFT @jovanpop-msft
+/articles/synapse-analytics/sql-data-warehouse/ @SnehaGunda @WilliamDAssafMSFT
 /articles/synapse-analytics/synapse-link/ @Rodrigossz @SnehaGunda @jovanpop-msft
 
 # Cognitive Services

articles/active-directory/conditional-access/TOC.yml

@@ -39,14 +39,16 @@
     href: service-dependencies.md
   - name: Location conditions
     href: location-condition.md
+  - name: Continuous access evaluation
+    href: concept-continuous-access-evaluation.md
   - name: Workload identities
     href: workload-identity.md
+  - name: CAE for workload identities
+    href: concept-continuous-access-evaluation-workload.md
   - name: Filter for devices
     href: concept-condition-filters-for-devices.md
   - name: What if tool
     href: what-if-tool.md
-  - name: Continuous access evaluation
-    href: concept-continuous-access-evaluation.md
 - name: How-to guides
   expanded: true
   items:

articles/active-directory/conditional-access/concept-continuous-access-evaluation-workload.md

@@ -0,0 +1,63 @@
+---
+title: Continuous access evaluation for workload identities in Azure AD
+description: Respond to changes to applications with continuous access evaluation for workload identities in Azure AD
+
+services: active-directory
+ms.service: active-directory
+ms.subservice: conditional-access
+ms.topic: conceptual
+ms.date: 07/22/2022
+
+ms.author: joflore
+author: MicrosoftGuyJFlo
+manager: karenhoran
+ms.reviewer: vmahtani
+
+ms.collection: M365-identity-device-management
+---
+# Continuous access evaluation for workload identities (preview)
+
+Continuous access evaluation (CAE) for [workload identities](../develop/workload-identities-overview.md) provides security benefits to your organization. It enables real-time enforcement of Conditional Access location and risk policies along with instant enforcement of token revocation events for workload identities. 
+
+Continuous access evaluation doesn't currently support managed identities.
+
+## Scope of preview
+
+The continuous access evaluation for workload identities public preview scope includes support for Microsoft Graph as a resource provider.
+
+The preview targets service principals for line of business (LOB) applications.
+
+We support the following revocation events:
+
+- Service principal disable
+- Service principal delete
+- High service principal risk as detected by Azure AD Identity Protection
+
+Continuous access evaluation for workload identities supports [Conditional Access policies that target location and risk](workload-identity.md#implementation).
+
+## Enable your application
+
+Developers can opt in to Continuous access evaluation for workload identities when their API requests `xms_cc` as an optional claim. The `xms_cc` claim with a value of `cp1` in the access token is the authoritative way to identify a client application is capable of handling a claims challenge. For more information about how to make this work in your application, see the article, [Claims challenges, claims requests, and client capabilities](../develop/claims-challenge.md).
+
+### Disable 
+
+In order to opt out, don't send the `xms_cc` claim with a value of `cp1`. 
+
+Organizations who have Azure AD Premium can create a [Conditional Access policy to disable continuous access evaluation](concept-conditional-access-session.md#customize-continuous-access-evaluation) applied to specific workload identities as an immediate stop-gap measure.
+
+## Troubleshooting
+
+When a client’s access to a resource is blocked due to CAE being triggered, the client’s session will be revoked, and the client will need to reauthenticate. This behavior can be verified in the sign-in logs. 
+
+The following steps detail how an admin can verify sign in activity in the sign-in logs: 
+
+1.	Sign into the Azure portal as a Conditional Access Administrator, Security Administrator, or Global Administrator.
+1.	Browse to **Azure Active Directory** > **Sign-in logs** > **Service Principal Sign-ins**. You can use filters to ease the debugging process. 
+1.	Select an entry to see activity details. The **Continuous access evaluation** field indicates whether a CAE token was issued in a particular sign-in attempt. 
+
+## Next steps
+
+- [Register an application with Azure AD and create a service principal](../develop/howto-create-service-principal-portal.md#register-an-application-with-azure-ad-and-create-a-service-principal)
+- [How to use Continuous Access Evaluation enabled APIs in your applications](../develop/app-resilience-continuous-access-evaluation.md)
+- [Sample application using continuous access evaluation](https://github.com/Azure-Samples/ms-identity-dotnetcore-daemon-graph-cae)
+- [What is continuous access evaluation?](../conditional-access/concept-continuous-access-evaluation.md)

articles/active-directory/develop/index-web-app.yml

@@ -39,7 +39,7 @@ landingContent:
           - text: ASP.NET
             url: tutorial-v2-asp-webapp.md
           - text: Blazor Server
-            url: tutorial-blazor-webassembly.md
+            url: tutorial-blazor-server.md
           - text: Node.js with Express
             url: tutorial-v2-nodejs-webapp-msal.md
   - title: "Web apps in depth"

articles/active-directory/fundamentals/security-operations-privileged-accounts.md

@@ -34,7 +34,7 @@ The log files you use for investigation and monitoring are:
 
 * [Azure AD Audit logs](../reports-monitoring/concept-audit-logs.md)
 * [Microsoft 365 Audit logs](/microsoft-365/compliance/auditing-solutions-overview)
-* [Azure Key Vault insights](../../azure-monitor/insights/key-vault-insights-overview.md)
+* [Azure Key Vault insights](../../key-vault/key-vault-insights-overview.md)
 
 From the Azure portal, you can view the Azure AD Audit logs and download as comma-separated value (CSV) or JavaScript Object Notation (JSON) files. The Azure portal has several ways to integrate Azure AD logs with other tools that allow for greater automation of monitoring and alerting:
 

articles/active-directory/roles/security-emergency-access.md

@@ -89,7 +89,7 @@ Some organizations use AD Domain Services and AD FS or similar identity provider
 
 ## Store account credentials safely
 
-Organizations need to ensure that the credentials for emergency access accounts are kept secure and known only to individuals who are authorized to use them. Some customers use a smartcard and others use passwords. A password for an emergency access account is usually separated into two or three parts, written on separate pieces of paper, and stored in secure, fireproof safes that are in secure, separate locations.
+Organizations need to ensure that the credentials for emergency access accounts are kept secure and known only to individuals who are authorized to use them. Some customers use a smartcard for Windows Server AD, a [FIDO2 security key](../authentication/howto-authentication-passwordless-security-key.md) for Azure AD and others use passwords. A password for an emergency access account is usually separated into two or three parts, written on separate pieces of paper, and stored in secure, fireproof safes that are in secure, separate locations.
 
 If using passwords, make sure the accounts have strong passwords that do not expire the password. Ideally, the passwords should be at least 16 characters long and randomly generated.
 

articles/aks/TOC.yml

@@ -507,6 +507,8 @@
           href: deployment-center-launcher.md
         - name: GitHub Actions for Kubernetes
           href: ../aks/kubernetes-action.md
+        - name: Configure automated deployments (preview)
+          href: automated-deployments.md
         - name: CI/CD with Azure Pipelines
           href: ../aks/devops-pipeline.md
     - name: Troubleshoot

articles/aks/automated-deployments.md

@@ -0,0 +1,72 @@
+---
+title: Automated deployments for Azure Kubernetes Service (Preview)
+description: Learn how to use automated deployments to simplify the process of adding GitHub Actions to your Azure Kubernetes Service (AKS) project
+ms.author: qpetraroia
+ms.topic: tutorial
+ms.date: 7/21/2022
+author: qpetraroia
+---
+
+# Automated Deployments for Azure Kubernetes Service (Preview)
+
+Automated deployments simplify the process of setting up a GitHub Action and creating an automated pipeline for your code releases to your Azure Kubernetes Service (AKS) cluster. Once connected, every new commit will kick off the pipeline, resulting in your application being updated.
+
+[!INCLUDE [preview features callout](./includes/preview/preview-callout.md)]
+
+> [!NOTE]
+> This feature is not yet available in all regions.
+
+## Prerequisites
+
+* A GitHub account.
+* An AKS cluster.
+* An Azure Container Registry (ACR)
+
+## Deploy an application to your AKS cluster
+
+1. In the Azure portal, navigate to the resource group containing the AKS cluster you want to deploy the application to.
+
+1. Select your AKS cluster, and then select **Automated deployments (preview)** on the left blade. Select **Create an automated deployment**.
+
+    :::image type="content" source="media/automated-deployments/ad-homescreen.png" alt-text="The automated deployments screen in the Azure portal."  lightbox="media/automated-deployments/ad-homescreen-expanded.png":::
+
+1. Name your workflow and click **Authorize** to connect your Azure account with your GitHub account. After your accounts are linked, choose which repository and branch you would like to create the GitHub Action for.
+
+    - **GitHub**: Authorize and select the repository for your GitHub account.
+
+        :::image type="content" source="media/automated-deployments/ad-ghactivate-repo.png" alt-text="The authorize and repository selection screen." lightbox="media/automated-deployments/ad-ghactivate-repo-expanded.png":::
+
+1. Pick your dockerfile and your ACR and image.
+
+    :::image type="content" source="media/automated-deployments/ad-image.png" alt-text="The image selection screen." lightbox="media/automated-deployments/ad-image-expanded.png":::
+
+1. Determine whether you'll deploy with Helm or regular Kubernetes manifests. Once decided, pick the appropriate deployment files from your repository and decide which namespace you want to deploy into.
+
+    :::image type="content" source="media/automated-deployments/ad-deployment-details.png" alt-text="The deployment details screen." lightbox="media/automated-deployments/ad-deployment-details-expanded.png":::
+
+1. Review your deployment before creating the pull request.
+
+1. Click **view pull request** to see your GitHub Action.
+
+    :::image type="content" source="media/automated-deployments/ad-view-pr.png" alt-text="The final screen of the deployment process. The view pull request button is highlighted." lightbox="media/automated-deployments/ad-view-pr-expanded.png" :::
+
+1. Merge the pull request to kick off the GitHub Action and deploy your application.
+
+    :::image type="content" source="media/automated-deployments/ad-accept-pr.png" alt-text="The pull request page in GitHub. The merge pull request button is highlighted." lightbox="media/automated-deployments/ad-accept-pr-expanded.png" :::
+
+1. Once your application is deployed, go back to automated deployments to see your history.
+
+    :::image type="content" source="media/automated-deployments/ad-view-history.png" alt-text="The history screen in Azure portal, showing all the previous automated deployments." lightbox="media/automated-deployments/ad-view-history-expanded.png" :::
+
+## Clean up resources
+
+You can remove any related resources that you created when you don't need them anymore individually or by deleting the resource group to which they belong. To delete your automated deployment, navigate to the automated deployment dashboard and select **...**, then select **delete** and confirm your action.
+
+## Next steps
+
+You can modify these GitHub Actions to meet the needs of your team by opening them up in an editor like Visual Studio Code and changing them as you see fit.
+
+Learn more about [GitHub Actions for Kubernetes][kubernetes-action].
+
+<!-- LINKS -->
+[kubernetes-action]: kubernetes-action.md

articles/aks/limit-egress-traffic.md

@@ -462,23 +462,20 @@ You'll define the outbound type to use the UDR that already exists on the subnet
 
 > [!NOTE]
 > AKS will create a system-assigned kubelet identity in the Node resource group if you do not [specify your own kubelet managed identity][Use a pre-created kubelet managed identity].
+> 
+> For user defined routing (UDR), system-assigned identity only supports CNI network plugin. Because for kubelet network plugin, AKS cluster needs permission on route table as kubernetes cloud-provider manages rules. 
 
-You can create an AKS cluster using a system-assigned managed identity by running the following CLI command.
+You can create an AKS cluster using a system-assigned managed identity with CNI network plugin by running the following CLI command.
 
 ```azurecli
 az aks create -g $RG -n $AKSNAME -l $LOC \
   --node-count 3 \
-  --network-plugin $PLUGIN \
+  --network-plugin azure \
   --outbound-type userDefinedRouting \
   --vnet-subnet-id $SUBNETID \
   --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][Create an AKS cluster with user-assigned identities]. For system-assigned control plane identity, we cannot get the identity ID before creating cluster, which causes delay for role assignment to take effect.
-
 #### Create an AKS cluster with user-assigned identities
 
 ##### Create user-assigned managed identities
@@ -529,14 +526,17 @@ The output should resemble the following:
 }
 ```
 
+> [!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]
+
 ##### Create an AKS cluster with user-assigned identities
 
 Now you can use the following command to create your AKS cluster with your existing identities in the subnet. Provide the control plane identity resource ID via `assign-identity` and the kubelet managed identity via `assign-kubelet-identity`:
 
 ```azurecli
 az aks create -g $RG -n $AKSNAME -l $LOC \
   --node-count 3 \
-  --network-plugin $PLUGIN \
+  --network-plugin kubenet \
   --outbound-type userDefinedRouting \
   --vnet-subnet-id $SUBNETID \
   --api-server-authorized-ip-ranges $FWPUBLIC_IP
@@ -545,8 +545,6 @@ az aks create -g $RG -n $AKSNAME -l $LOC \
   --assign-kubelet-identity <kubelet-identity-resource-id>
 ```
 
-> [!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]
 
 ### Enable developer access to the API server