Merge pull request #134818 from MicrosoftDocs/repo_sync_working_branch

huypub · web-flow · commit 431d1e11042b · 2020-10-21T14:50:39.000-07:00
Confirm merge from repo_sync_working_branch to master to sync with https://github.com/MicrosoftDocs/azure-docs (branch master)
diff --git a/articles/aks/faq.md b/articles/aks/faq.md
@@ -195,6 +195,13 @@ No, AKS is a managed service, and manipulation of the IaaS resources is not supp
 
 The feature to enable storing customer data in a single region is currently only available in the Southeast Asia Region (Singapore) of the Asia Pacific Geo. For all other regions, customer data is stored in Geo.
 
+## Are AKS images required to run as root?
+
+Except for the following two images, AKS images are not required to run as root:
+
+- *mcr.microsoft.com/oss/kubernetes/coredns*
+- *mcr.microsoft.com/azuremonitor/containerinsights/ciprod*
+
 <!-- LINKS - internal -->
 
 [aks-upgrade]: ./upgrade-cluster.md
diff --git a/articles/aks/view-master-logs.md b/articles/aks/view-master-logs.md
@@ -33,9 +33,11 @@ Azure Monitor logs are enabled and managed in the Azure portal. To enable log co
 
 In addition to entries written by Kubernetes, your project's audit logs also have entries from AKS.
 
-Audit logs are recorded into two categories, *kube-audit-admin* and *kube-audit*. The *kube-audit* category contains all audit log data for every audit event, including *get*, *list*, *create*, *update*, *delete*, *patch*, and *post*.
+Audit logs are recorded into three categories: *kube-audit*, *kube-audit-admin*, and *guard*.
 
-The *kube-audit-admin* category is a subset of the *kube-audit* log category. *kube-audit-admin* reduces the number of logs significantly by excluding the *get* and *list* audit events from the log.
+- The *kube-audit* category contains all audit log data for every audit event, including *get*, *list*, *create*, *update*, *delete*, *patch*, and *post*.
+- The *kube-audit-admin* category is a subset of the *kube-audit* log category. *kube-audit-admin* reduces the number of logs significantly by excluding the *get* and *list* audit events from the log.
+- The *guard* category is managed Azure AD and Azure RBAC audits. For managed Azure AD: token in, user info out. For Azure RBAC: access reviews in and out.
 
 ## Schedule a test pod on the AKS cluster
 
@@ -71,7 +73,7 @@ pod/nginx created
 
 ## View collected logs
 
-It may take a few minutes for the diagnostics logs to be enabled and appear.
+It may take up to 10 minutes for the diagnostics logs to be enabled and appear.
 
 > [!NOTE]
 > If you need all audit log data for compliance or other purposes, collect and store it in inexpensive storage such as blob storage. Use the *kube-audit-admin* log category to collect and save a meaningful set of audit log data for monitoring and alerting purposes.
diff --git a/articles/azure-functions/functions-bindings-event-hubs-trigger.md b/articles/azure-functions/functions-bindings-event-hubs-trigger.md
@@ -8,7 +8,7 @@ ms.date: 02/21/2020
 ms.author: cshoe
 ---
 
-# Azure Event Hubs bindings for Azure Functions
+# Azure Event Hubs trigger for Azure Functions
 
 This article explains how to work with [Azure Event Hubs](../event-hubs/event-hubs-about.md) trigger for Azure Functions. Azure Functions supports trigger and [output bindings](functions-bindings-event-hubs-output.md) for Event Hubs.
 
diff --git a/articles/azure-monitor/platform/move-workspace.md b/articles/azure-monitor/platform/move-workspace.md
@@ -36,11 +36,20 @@ Solutions that must be removed before you can unlink your automation account:
 
 >[!IMPORTANT]
 > **Azure Sentinel customers**
-> - Once deployed on a workspace, Azure Sentinel **does not currently support** the moving of that workspace to other resource groups or subscriptions. 
-> - If you have already moved the workspace, disable all active rules under **Analytics** and re-enable them after five minutes. This should be effective in most cases, though, to reiterate, it is unsupported and undertaken at your own risk.
+> - Currently, after Azure Sentinel is deployed on a workspace, moving the workspace to another resource group or subscription isn't supported. 
+> - If you have already moved the workspace, disable all active rules under **Analytics** and re-enable them after five minutes. This should be an effective solution in most cases, though, to reiterate, it is unsupported and undertaken at your own risk.
 > 
-> **Alerts**
-> - All alerts needs to re-create after the move, since the permissions are based on the Azure Resource ID of the workspace and it's changes with the workspace move. 
+> **Re-create alerts**
+> - All alerts must be re-created after a move because the permissions are based on the Azure Resource ID of the workspace, which changes during a workspace move.
+>
+> **Update resource paths**
+> - After a workspace move, any Azure or external resources that point to the workspace must be reviewed and updated to point to the new resource target path.
+> 
+>   *Examples:*
+>   - [Azure Monitor alert rules](alerts-resource-move.md)
+>   - Third-party applications
+>   - Custom scripting
+>
 
 ### Delete solutions in Azure portal
 Use the following procedure to remove the solutions using the Azure portal:
diff --git a/articles/azure-monitor/samples/resource-manager-alerts-log.md b/articles/azure-monitor/samples/resource-manager-alerts-log.md
@@ -32,7 +32,7 @@ The following sample creates a [number of results alert rule](../platform/alerts
             "type": "string",
             "defaultValue": "",
             "metadata": {
-                "description": "Resource ID of the Log Analytisc workspace."
+                "description": "Resource ID of the Log Analytics workspace."
             }
         },
         "location": {
diff --git a/articles/azure-vmware/tutorial-deploy-vmware-hcx.md b/articles/azure-vmware/tutorial-deploy-vmware-hcx.md
@@ -60,7 +60,9 @@ Infrastructure components must be running the required minimum version.
 
 * Configure [Azure ExpressRoute Global Reach](tutorial-expressroute-global-reach-private-cloud.md) between on-premises and Azure VMware Solution SDDC ExpressRoute circuits.
 
-* All required ports should be open for communication between on-premises components and Azure VMware Solution SDDC. For more information, see [VMware HCX documentation](https://docs.vmware.com/en/VMware-HCX/services/user-guide/GUID-E456F078-22BE-494B-8E4B-076EF33A9CF4.html).
+* [All required ports](https://ports.vmware.com/home/VMware-HCX) should be open for communication between on-premises components and Azure VMware Solution SDDC.
+
+For more information, see the [VMware HCX documentation](https://docs.vmware.com/en/VMware-HCX/services/user-guide/GUID-E456F078-22BE-494B-8E4B-076EF33A9CF4.html).
 
 
 ### IP addresses
@@ -69,13 +71,13 @@ Infrastructure components must be running the required minimum version.
    
 ## Deploy the VMware HCX Connector OVA on-premises
 
->[!NOTE]
->Before you deploy the virtual appliance to your on-premises vCenter, you'll need to download the VMware HCX Connector OVA. 
+> [!NOTE]
+> Before you deploy the virtual appliance to your on-premises vCenter, you must download the VMware HCX Connector OVA. 
 
 1. Open a browser window, sign in to the Azure VMware Solution HCX Manager on `https://x.x.x.9` port 443 with the **cloudadmin** user credentials, and then go to **Support**.
 
-   >[!TIP]
-   >Note the IP address of the HCX Cloud Manager in Azure VMware Solution. To identify the IP address, on the Azure VMware Solution pane, go to **Manage** > **Connectivity** and then select the **HCX** tab. 
+   > [!TIP]
+   > Note the IP address of the HCX Cloud Manager in Azure VMware Solution. To identify the IP address, on the Azure VMware Solution pane, go to **Manage** > **Connectivity** and then select the **HCX** tab. 
    >
    >The vCenter password was defined when you set up the private cloud.
 
@@ -98,8 +100,8 @@ Infrastructure components must be running the required minimum version.
 
 1. Select **Next**, verify the configuration, and then select **Finish** to deploy the HCX Connector OVA.
      
-   >[!NOTE]
-   >Generally, the VMware HCX Connector that you're deploying now is deployed onto the cluster's management network.  
+   > [!NOTE]
+   > Generally, the VMware HCX Connector that you're deploying now is deployed onto the cluster's management network.  
    
    > [!IMPORTANT]
    > You might need to turn on the virtual appliance manually.  If that's the case, wait 10-15 minutes before proceeding to the next step.
@@ -167,7 +169,7 @@ You can connect (pair) the VMware HCX Cloud Manager in Azure VMware Solution wit
 1. Enter the Remote HCX URL or IP address that you noted earlier, the Azure VMware Solution cloudadmin@vsphere.local username, and the password. Then select **Connect**.
 
    > [!NOTE]
-   > The remote HCX URL is your Azure VMware Solution private cloud's HCX Cloud Manager IP address, which is the ".9" address of the management network. For example, if your vCenter is 192.168.4.2, then your HCX URL will be 192.168.4.9.
+   > To establish a site pair successfully, your HCX connector must be able to route to your HCX Cloud Manager IP over port 443.
    >
    > The password is the same password that you used to sign in to vCenter. You defined this password on the initial deployment screen.
 
@@ -268,6 +270,13 @@ For an end-to-end overview of this procedure, view the [Azure VMware Solution: C
 
 Now it's time to configure a service mesh between on-premises and Azure VMware Solution SDDC.
 
+   > [!NOTE]
+   > To successfully establish a service mesh with Azure VMware Solution:
+   >
+   > Ports UDP 500/4500 are open between your on-premises HCX connector-defined 'uplink' network profile addresses and the Azure VMware Solution HCX Cloud 'uplink' network profile addresses.
+   >
+   > Be sure to review [HCX required ports](https://ports.vmware.com/home/VMware-HCX).
+
 1. Under **Infrastructure**, select **Interconnect** > **Service Mesh** > **Create Service Mesh**.    
 
    :::image type="content" source="media/tutorial-vmware-hcx/create-service-mesh.png" alt-text="Screenshot of selections to start creating a service mesh." lightbox="media/tutorial-vmware-hcx/create-service-mesh.png":::
@@ -347,3 +356,4 @@ For more information on using HCX, go to the VMware technical documentation:
 
 * [VMware HCX Documentation](https://docs.vmware.com/en/VMware-HCX/index.html)
 * [Migrating Virtual Machines with VMware HCX](https://docs.vmware.com/en/VMware-HCX/services/user-guide/GUID-D0CD0CC6-3802-42C9-9718-6DA5FEC246C6.html?hWord=N4IghgNiBcIBIGEAaACAtgSwOYCcwBcMB7AOxAF8g).
+* [HCX required ports](https://ports.vmware.com/home/VMware-HCX)
diff --git a/articles/cosmos-db/performance-tips-java-sdk-v4-sql.md b/articles/cosmos-db/performance-tips-java-sdk-v4-sql.md
@@ -159,13 +159,13 @@ Please see the [Windows](https://docs.microsoft.com/azure/virtual-network/create
 
         As a first step, use the following recommended configuration settings below. These *DirectConnectionConfig* options are advanced configuration settings which can affect SDK performance in unexpected ways; we recommend users avoid modifying them unless they feel very comfortable in understanding the tradeoffs and it is absolutely necessary. Please contact the [Azure Cosmos DB team](mailto:CosmosDBPerformanceSupport@service.microsoft.com) if you run into issues on this particular topic.
 
-        | Configuration option       | Default    |
-        | :------------------:       | :-----:    |
-        | idleConnectionTimeout      | "PT1M"     |
-        | maxConnectionsPerEndpoint  | "PT0S"     |
-        | connectTimeout             | "PT1M10S"  |
-        | idleEndpointTimeout        | 8388608    |
-        | maxRequestsPerConnection   | 10         |
+        | Configuration option       | Default   |
+        | :------------------:       | :-----:   |
+        | idleConnectionTimeout      | "PT0"     |
+        | maxConnectionsPerEndpoint  | "130"     |
+        | connectTimeout             | "PT5S"    |
+        | idleEndpointTimeout        | "PT1H"    |
+        | maxRequestsPerConnection   | "30"      |
 
 * **Tuning parallel queries for partitioned collections**
 
diff --git a/articles/databox-online/azure-stack-edge-gpu-activation-key-vault.md b/articles/databox-online/azure-stack-edge-gpu-activation-key-vault.md
@@ -18,7 +18,7 @@ Azure Key Vault is integrated with Azure Stack Edge resource for secret manageme
 
 ## About Key vault and Azure Stack Edge
 
-Azure Key Vault cloud service is used to securely store and control access to tokens, passwords, certificates, API keys, and other secrets. Key Vault also makes it easy to create and control the encryption keys used to encrypt your data. 
+Azure Key Vault cloud service is used to securely store and control access to tokens, passwords, certificates, API keys, and other secrets. Key Vault also makes it easy to create and control the encryption keys used to encrypt your data. For more information about allowed transactions and corresponding charges, see [Pricing for Azure Key Vault](https://azure.microsoft.com/pricing/details/key-vault/).
 
 For Azure Stack Edge service, one of the secrets used is Channel Integrity Key (CIK). This key allows you to encrypt your secrets. With the integration of key vault, the CIK is securely stored in the key vault. For more information, see [Securely store secrets and keys](../key-vault/general/overview.md#securely-store-secrets-and-keys).
 
@@ -41,6 +41,8 @@ A key vault is created for Azure Stack Edge resource during the process of activ
 
     ![MSI created during Azure Stack Edge resource creation](media/azure-stack-edge-gpu-deploy-prep/create-resource-8.png)
 
+- To browse to the Azure key vault, go to the **Properties** in your Azure Stack Edge resource and select the key vault name. 
+
 - To prevent accidental deletion, a resource lock is enabled on the key vault. A soft-delete is also enabled on the key vault that allows the key vault to be restored within 90 days if there is an accidental deletion. For more information, see [Azure Key Vault soft-delete overview](../key-vault/general/soft-delete-overview.md)
 
     If the key vault is accidentally deleted and the purge protection duration of 90 days hasn't elapsed, follow these steps to [Recover your key vault](../key-vault/general/soft-delete-powershell.md#recovering-a-key-vault). 
diff --git a/articles/event-hubs/authenticate-managed-identity.md b/articles/event-hubs/authenticate-managed-identity.md
@@ -25,7 +25,7 @@ To authorize a request to Event Hubs service from a managed identity in your app
 For more information about assigning Azure roles, see [Authenticate with Azure Active Directory for access to Event Hubs resources](authorize-access-azure-active-directory.md).
 
 ## Use Event Hubs with managed identities
-To use Event Hubs with managed identities, you need to assign the identity the role and the appropriate scope. The procedure in this section uses a simple application that runs under a managed identity and accesses Event Hubs resources.
+To use Event Hubs with managed identities, you need to assign the role and the appropriate scope to the identity. The procedure in this section uses a simple application that runs under a managed identity and accesses Event Hubs resources.
 
 Here we're using a sample web application hosted in [Azure App Service](https://azure.microsoft.com/services/app-service/). For step-by-step instructions for creating a web application, see [Create an ASP.NET Core web app in Azure](../app-service/quickstart-dotnetcore.md)
 
diff --git a/articles/expressroute/expressroute-howto-set-global-reach.md b/articles/expressroute/expressroute-howto-set-global-reach.md
@@ -102,17 +102,17 @@ When the previous operation completes, you will have connectivity between your o
 
 Use the following command to verify the configuration on the circuit where the configuration was made (for example, circuit 1 in the previous example).
 ```azurepowershell-interactive
-$ckt1 = Get-AzExpressRouteCircuit -Name "Your_circuit_1_name" -ResourceGroupName "Your_resource_group"
+$ckt_1 = Get-AzExpressRouteCircuit -Name "Your_circuit_1_name" -ResourceGroupName "Your_resource_group"
 ```
 
-If you simply run *$ckt1* in PowerShell, you see *CircuitConnectionStatus* in the output. It tells you whether the connectivity is established, "Connected", or "Disconnected". 
+If you simply run *$ckt_1* in PowerShell, you see *CircuitConnectionStatus* in the output. It tells you whether the connectivity is established, "Connected", or "Disconnected". 
 
 ## Disable connectivity
 
 To disable connectivity between your on-premises networks, run the commands against the circuit where the configuration was made (for example, circuit 1 in the previous example).
 
 ```azurepowershell-interactive
-$ckt1 = Get-AzExpressRouteCircuit -Name "Your_circuit_1_name" -ResourceGroupName "Your_resource_group"
+$ckt_1 = Get-AzExpressRouteCircuit -Name "Your_circuit_1_name" -ResourceGroupName "Your_resource_group"
 Remove-AzExpressRouteCircuitConnectionConfig -Name "Your_connection_name" -ExpressRouteCircuit $ckt_1
 Set-AzExpressRouteCircuit -ExpressRouteCircuit $ckt_1
 ```
diff --git a/articles/hdinsight/hbase/apache-hbase-tutorial-get-started-linux.md b/articles/hdinsight/hbase/apache-hbase-tutorial-get-started-linux.md
@@ -223,6 +223,31 @@ HBase data can also be queried from Hive using ESP-enabled HBase:
 
 The REST API is secured via [basic authentication](https://en.wikipedia.org/wiki/Basic_access_authentication). You shall always make requests by using Secure HTTP (HTTPS) to help ensure that your credentials are securely sent to the server.
 
+1. To enable HBase REST APIs in the HDInsight cluster, add the following custom startup script to the **Script Action** section. You can add the startup script when you create the cluster or after the cluster has been created. For **Node Type**, select **Region Servers** to ensure that the script executes only in HBase Region Servers.
+
+
+	```bash
+	#! /bin/bash
+
+	THIS_MACHINE=`hostname`
+
+	if [[ $THIS_MACHINE != wn* ]]
+	then
+		printf 'Script to be executed only on worker nodes'
+		exit 0
+	fi
+
+	RESULT=`pgrep -f RESTServer`
+	if [[ -z $RESULT ]]
+	then
+		echo "Applying mitigation; starting REST Server"
+		sudo python /usr/lib/python2.7/dist-packages/hdinsight_hbrest/HbaseRestAgent.py
+	else
+		echo "Rest server already running"
+		exit 0
+	fi
+	```
+
 1. Set environment variable for ease of use. Edit the commands below by replacing `MYPASSWORD` with the cluster login password. Replace `MYCLUSTERNAME` with the name of your HBase cluster. Then enter the commands.
 
     ```bash
diff --git a/articles/key-vault/general/key-vault-integrate-kubernetes.md b/articles/key-vault/general/key-vault-integrate-kubernetes.md
@@ -181,6 +181,7 @@ If you're using a service principal, grant permissions for it to access your key
 1. Grant the service principal permissions to get secrets:
     ```azurecli
     az keyvault set-policy -n $KEYVAULT_NAME --secret-permissions get --spn $AZURE_CLIENT_ID
+    az keyvault set-policy -n $KEYVAULT_NAME --key-permissions get --spn $AZURE_CLIENT_ID
     ```
 
 1. You've now configured your service principal with permissions to read secrets from your key vault. The **$AZURE_CLIENT_SECRET** is the password of your service principal. Add your service principal credentials as a Kubernetes secret that's accessible by the Secrets Store CSI driver:
@@ -233,6 +234,7 @@ If you're using managed identities, assign specific roles to the AKS cluster you
     az role assignment create --role "Reader" --assignee $principalId --scope /subscriptions/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/resourceGroups/contosoResourceGroup/providers/Microsoft.KeyVault/vaults/contosoKeyVault5
 
     az keyvault set-policy -n contosoKeyVault5 --secret-permissions get --spn $clientId
+    az keyvault set-policy -n contosoKeyVault5 --key-permissions get --spn $clientId
     ```
 
 ## Deploy your pod with mounted secrets from your key vault
@@ -305,8 +307,8 @@ spec:
         readOnly: true
         volumeAttributes:
           secretProviderClass: azure-kvname
-        nodePublishSecretRef:
-          name: secrets-store-creds 
+        nodePublishSecretRef:           # Only required when using service principal mode
+          name: secrets-store-creds     # Only required when using service principal mode
 ```
 
 Run the following command to deploy your pod:
diff --git a/articles/private-link/private-endpoint-dns.md b/articles/private-link/private-endpoint-dns.md
diff --git a/articles/security-center/tutorial-security-incident.md b/articles/security-center/tutorial-security-incident.md
diff --git a/articles/storage/common/storage-sas-overview.md b/articles/storage/common/storage-sas-overview.md
diff --git a/articles/virtual-machines/linux/optimization.md b/articles/virtual-machines/linux/optimization.md

Original file line number	Diff line number	Diff line change
`@@ -32,7 +32,7 @@ The following sample creates a [number of results alert rule](../platform/alerts`
`32`	`32`	`"type": "string",`
`33`	`33`	`"defaultValue": "",`
`34`	`34`	`"metadata": {`
`35`		`- "description": "Resource ID of the Log Analytisc workspace."`
	`35`	`+ "description": "Resource ID of the Log Analytics workspace."`
`36`	`36`	`}`
`37`	`37`	`},`
`38`	`38`	`"location": {`