Merge pull request #100948 from bandersmsft/release-mvc-cost-mgt-billing

cost mgt billing - Dirty PR for release branch merge conflict with upstream master

Author: ktoliver

.openpublishing.redirection.json

@@ -85446,6 +85446,11 @@
       "redirect_url": "/azure/azure-databricks/databricks-extract-load-sql-data-warehouse",
       "redirect_document_id": false
     },
+    {
+      "source_path": "articles/azure-databricks/vnet-injection.md",
+      "redirect_url": "/azure/databricks/administration-guide/cloud-configurations/azure/vnet-inject",
+      "redirect_document_id": false
+    },
     {
       "source_path": "articles/security/blueprints/gdpr-analytics-overview.md",
       "redirect_url": "https://aka.ms/azureblueprint",

articles/aks/azure-disk-customer-managed-keys.md

@@ -6,7 +6,7 @@ author: mlearned
 
 ms.service: container-service
 ms.topic: article
-ms.date: 01/09/2020
+ms.date: 01/12/2020
 ms.author: mlearned
 ---
 
@@ -57,7 +57,7 @@ az account list-locations
 az group create -l myAzureRegionName -n myResourceGroup
 
 # Create an Azure Key Vault resource in a supported Azure region
-az keyvault create -n myKeyVaultName -g myResourceGroup-l myAzureRegionName  --enable-purge-protection true --enable-soft-delete true
+az keyvault create -n myKeyVaultName -g myResourceGroup -l myAzureRegionName  --enable-purge-protection true --enable-soft-delete true
 ```
 
 ## Create an instance of a DiskEncryptionSet
@@ -72,7 +72,7 @@ keyVaultId=$(az keyvault show --name myKeyVaultName --query [id] -o tsv)
 keyVaultKeyUrl=$(az keyvault key show --vault-name myKeyVaultName  --name myKeyName  --query [key.kid] -o tsv)
 
 # Create a DiskEncryptionSet
-az disk-encryption-set create -n myDiskEncryptionSetName  -l myAzureRegionName  -g myResourceGroup--source-vault $keyVaultId --key-url $keyVaultKeyUrl 
+az disk-encryption-set create -n myDiskEncryptionSetName  -l myAzureRegionName  -g myResourceGroup --source-vault $keyVaultId --key-url $keyVaultKeyUrl 
 ```
 
 ## Grant the DiskEncryptionSet resource access to the key vault
@@ -81,46 +81,37 @@ Use the DiskEncryptionSet and resource groups you created on the prior steps, an
 
 ```azurecli-interactive
 # Retrieve the DiskEncryptionSet value and set a variable
-desIdentity=$(az disk-encryption-set show -n myDiskEncryptionSetName  -g myResourceGroup--query [identity.principalId] -o tsv)
+desIdentity=$(az disk-encryption-set show -n myDiskEncryptionSetName  -g myResourceGroup --query [identity.principalId] -o tsv)
 
 # Update security policy settings
-az keyvault set-policy -n myKeyVaultName -g myResourceGroup--object-id $desIdentity --key-permissions wrapkey unwrapkey get
+az keyvault set-policy -n myKeyVaultName -g myResourceGroup --object-id $desIdentity --key-permissions wrapkey unwrapkey get
 
 # Assign the reader role
 az role assignment create --assignee $desIdentity --role Reader --scope $keyVaultId
 ```
 
 ## Create a new AKS cluster and encrypt the OS disk with a customer-manged key
 
-Create a new resource group and AKS cluster, then use your key to encrypt the OS disk.
+Create a new resource group and AKS cluster, then use your key to encrypt the OS disk. Customer managed key is only supported in kubernetes versions greater than 1.17
 
 ```azurecli-interactive
 # Retrieve the DiskEncryptionSet value and set a variable
-diskEncryptionSetId=$(az resource show -n $diskEncryptionSetName -g ssecmktesting --resource-type "Microsoft.Compute/diskEncryptionSets" --query [id] -o tsv)
+diskEncryptionSetId=$(az resource show -n diskEncryptionSetName -g myResourceGroup --resource-type "Microsoft.Compute/diskEncryptionSets" --query [id] -o tsv)
 
 # Create a resource group for the AKS cluster
 az group create -n myResourceGroup-l myAzureRegionName
 
 # Create the AKS cluster
-az aks create -n myAKSCluster -g myResourceGroup --node-osdisk-diskencryptionsetid diskEncryptionId
+az aks create -n myAKSCluster -g myResourceGroup --node-osdisk-diskencryptionset-id $diskEncryptionSetId --kubernetes-version 1.17.0
 ```
 
-## Add a node pool to an existing AKS cluster and encrypt the OS disk with a customer-managed key
-
-New nodepools do not use encrypted disks by default.  You can add a new node pool to an existing cluster and encrypt the OS disk with your own key by using the following command.
-
-```azurecli-interactive
-# Add a nodepool to an existing cluster with BYOK encryption
-nodepool add –-cluster-name myAKSCluster -n myNodePoolName -g myResourceGroup --node-osdisk-diskencryptionsetid diskEncryptionId  
-```
+When new node pools are added to the cluster created above, the customer managed key provided during the create is used to encrypt the OS disk
 
 ## Encrypt your AKS cluster data disk with a customer-managed key
 
 You can also encrypt the AKS data disks with your own keys.  Replace myResourceGroup and myDiskEncryptionSetName with your real values, and apply the yaml.
 
-### Deploy the sample image from ACR to AKS
-
-Ensure you have the proper AKS credentials
+Ensure you have the proper AKS credentials. The Service principal will need to have contributor access to the resource group where the diskencryptionset is present. Otherwise, you will get an error suggesting that the service principal does not have permissions.
 
 Create a file called **byok-azure-disk.yaml** that contains the following information.  Replace myResourceGroup and myDiskEncrptionSetName with your values.
 

articles/app-service/app-service-web-get-started-windows-container.md

@@ -159,15 +159,15 @@ The streamed logs looks like this:
 
 ## Use a different parent image
 
-You're free to use a different custom Docker image to run your app. However, you must choose the right [parent image](https://docs.docker.com/develop/develop-images/baseimages/) for the framework you want:
+You're free to use a different custom Docker image to run your app. However, you must choose the right [parent image (base image)](https://docs.docker.com/develop/develop-images/baseimages/) for the framework you want:
 
 - To deploy .NET Framework apps, use a parent image based on the Windows Server Core 2019 [Long-Term Servicing Channel (LTSC)](https://docs.microsoft.com/windows-server/get-started-19/servicing-channels-19#long-term-servicing-channel-ltsc) release. 
 - To deploy .NET Core apps, use a parent image based on the Windows Server Nano 1809 [Semi-Annual Servicing Channel (SAC)](https://docs.microsoft.com/windows-server/get-started-19/servicing-channels-19#semi-annual-channel) release. 
 
 It takes some time to download a parent image during app start-up. However, you can reduce start-up time by using one of the following parent images that are already cached in Azure App Service:
 
 - [mcr.microsoft.com/dotnet/framework/aspnet](https://hub.docker.com/_/microsoft-dotnet-framework-aspnet/):4.7.2-windowsservercore-ltsc2019
-- [mcr.microsoft.com/windows/nanoserver](https://hub.docker.com/_/microsoft-windows-nanoserver/):1809 - this image is the base container used across Microsoft [ASP.NET Core](https://hub.docker.com/_microsoft-dotnet-cores-aspnet) Microsoft Windows Nano Server images.
+- [mcr.microsoft.com/windows/nanoserver](https://hub.docker.com/_/microsoft-windows-nanoserver/):1809 - this image is the base container used across Microsoft [ASP.NET Core](https://hub.docker.com/_/microsoft-dotnet-core-aspnet/) Microsoft Windows Nano Server images.
 
 ## Next steps
 

articles/app-service/containers/how-to-configure-python.md

@@ -46,7 +46,7 @@ az webapp config set --resource-group <resource-group-name> --name <app-name> --
 
 ## Container characteristics
 
-Python apps deployed to App Service on Linux run within a Docker container that's defined in the GitHub repository, [Python 3.6](https://github.com/Azure-App-Service/python/tree/master/3.6.6) or [Python 3.7](https://github.com/Azure-App-Service/python/tree/master/3.7.0).
+Python apps deployed to App Service on Linux run within a Docker container that's defined in the [App Service Python GitHub repository](https://github.com/Azure-App-Service/python). You can find the image configurations inside the version-specific directories.
 
 This container has the following characteristics:
 

articles/app-service/containers/toc.yml

@@ -180,7 +180,7 @@
   - name: Azure CLI
     href: /cli/azure/appservice
   - name: Azure PowerShell
-    href: /powershell
+    href: /powershell/module/az.websites/#app_service
   - name: REST API
     href: /rest/api/appservice/
 - name: Resources

articles/app-service/deploy-zip.md

@@ -85,6 +85,8 @@ For more information, see [Kudu documentation](https://github.com/projectkudu/ku
 
 To deploy a WAR file to App Service, send a POST request to `https://<app_name>.scm.azurewebsites.net/api/wardeploy`. The POST request must contain the .war file in the message body. The deployment credentials for your app are provided in the request by using HTTP BASIC authentication.
 
+Always use `/api/wardeploy` when deploying WAR files. This API will expand your WAR file and place it on the shared file drive. using other deployment APIs may result in inconsistent behavior. 
+
 For the HTTP BASIC authentication, you need your App Service deployment credentials. To see how to set your deployment credentials, see [Set and reset user-level credentials](deploy-configure-credentials.md#userscope).
 
 ### With cURL

articles/app-service/toc.yml

@@ -220,7 +220,7 @@
   - name: Azure CLI
     href: /cli/azure/appservice
   - name: Azure PowerShell
-    href: /powershell
+    href: /powershell/module/az.websites/#app_service
   - name: REST API
     href: /rest/api/appservice/
   - name: Resource Manager template

articles/automation/TOC.yml

@@ -15,6 +15,8 @@
       displayName: certificate renewal
     - name: Configure authentication with AWS
       href: automation-config-aws-account.md
+    - name: Encryption of secure assets in Azure Automation
+      href: automation-secure-asset-encryption.md
     - name: Manage role-based access control
       href: automation-role-based-access-control.md
       displayName: RBAC

articles/automation/automation-secure-asset-encryption.md

@@ -0,0 +1,189 @@
+---
+title: Encryption of secure assets in automation
+description: Azure automation protects secure assets using multiple levels of encryption. By default, the encryption is done using Microsoft-managed keys. Customers can configure their automation accounts to use customer managed keys for encryption. This article describes the details of both modes of encryption and how you can switch between the two.
+services: automation
+ms.service: automation
+ms.subservice: process-automation
+author: snehithm
+ms.author: snmuvva
+ms.date: 01/11/2020
+ms.topic: conceptual
+manager: kmadnani
+---
+
+# Secure assets in Azure Automation
+
+Secure assets in Azure Automation include credentials, certificates, connections, and encrypted variables. These assets are protected in Azure Automation using multiple levels of encryption. 
+Based on the top-level key used for the encryption, there are two models for encryption:
+-	Using Microsoft-managed keys
+-	Using customer-managed keys
+
+## Microsoft-managed Keys
+
+By default, your Azure Automation account uses Microsoft-managed keys.
+
+Each secure asset is encrypted and stored in Azure Automation using a unique key (Data Encryption key) that is generated for each automation account. These keys themselves are encrypted and stored in Azure Automation using yet another unique key that is generated for each account called an Account Encryption Key (AEK). These account encryption keys encrypted and stored in Azure Automation using Microsoft Managed Keys. 
+
+## Customer-managed Keys with Key Vault (preview)
+
+You can manage encryption of secure assets in Azure Automation at the level of an automation account with your own keys. When you specify a customer-managed key at the level of the Automation account, that key is used to protect and control access to the account encryption key for the automation account, which in turn is used to encrypt and decrypt all the secure assets. Customer-managed keys offer greater flexibility to create, rotate, disable, and revoke access controls. You can also audit the encryption keys used to protect your secure assets. 
+
+You must use Azure Key Vault to store customer-managed keys. You can either create your own keys and store them in a key vault, or you can use the Azure Key Vault APIs to generate keys.  For more information about Azure Key Vault, see [What is Azure Key Vault?](../key-vault/key-vault-overview.md)
+
+## Enable customer-managed keys for an Automation account
+
+When you enable encryption with customer-managed keys for an automation account, Azure Automation wraps the account encryption key with the customer-managed key in the associated key vault. Enabling customer-managed keys does not impact performance, and the account is encrypted with the new key immediately, without any time delay.
+
+A new automation account is always encrypted using Microsoft-managed keys. It's not possible to enable customer-managed keys at the time that the account is created. Customer-managed keys are stored in Azure Key Vault, and the key vault must be provisioned with access policies that grant key permissions to the managed identity that is associated with the automation account. The managed identity is available only after the storage account is created.
+
+When you modify the key being used for Azure Automation secure asset encryption by enabling or disabling customer-managed keys, updating the key version, or specifying a different key, then the encryption of the account encryption key changes, but the secure assets in your Azure Automation account do not need to be re-encrypted.
+
+The following three sections describe the mechanics of enabling customer-managed keys for an Automation account. 
+
+> [!NOTE] 
+> To enable customer-managed keys, you will currently need to make Azure Automation REST API calls using api version 2020-01-13-preview
+
+### Pre-requisites for using Customer-managed keys in Azure Automation
+
+Before enabling customer-managed keys for an Automation account, you must ensure the following pre-requisites are met
+
+ - The customer-manged key is stored in an Azure Key Vault. 
+ - You must enable both the **Soft Delete** and **Do Not Purge** properties on the key vault. These features are required to allow for recovery of keys in case of accidental deletion.
+ - Only RSA keys are supported with Azure Automation encryption. For more information about keys, see [About Azure Key Vault keys, secrets, and certificates](../key-vault/about-keys-secrets-and-certificates.md#key-vault-keys).
+- The automation account and the key vault can be in different subscriptions but need to be in the same Azure Active Directory tenant.
+
+### Assign an identity to the automation account
+
+To use customer-managed keys with an automation account, your automation account needs to authenticate against the keyvault storing customer-managed keys. Azure Automation uses system assigned managed identities to authenticate the account with Key Vault. For more information about managed identities, see [What is managed identities for Azure resources?](https://docs.microsoft.com/azure/active-directory/managed-identities-azure-resources/overview)
+
+Configure a system assigned managed identity to the automation account using the following REST API call
+
+```http
+PATCH https://management.azure.com/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/resource-group-name/providers/Microsoft.Automation/automationAccounts/automation-account-name?api-version=2020-01-13-preview
+```
+Request body
+```json
+{ 
+ "identity": 
+ { 
+  "type": "SystemAssigned" 
+  } 
+}
+```    
+
+System assigned identity for the automation account is returned in the response
+
+```json
+{
+ "name": "automation-account-name",
+ "id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/resource-group-name/providers/Microsoft.Automation/automationAccounts/automation-account-name",
+ ..
+ "identity": {
+    "type": "SystemAssigned",
+    "principalId": "aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa",
+    "tenantId": "bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb"
+ },
+..
+}
+```
+
+### Configure the Key Vault access policy
+
+Once a managed identity is assigned to the Automation account, you configure access to the Key Vault storing customer managed Keys. Azure Automation requires **get**, **recover**, **wrapKey**, **UnwrapKey** on the customer managed keys.
+
+Such an access policy can be set using the following REST API call.
+
+```http
+PUT https://management.azure.com/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/sample-group/providers/Microsoft.KeyVault/vaults/sample-vault/accessPolicies/add?api-version=2018-02-14
+```
+Request body
+
+```json
+{
+  "properties": {
+    "accessPolicies": [
+      {
+        "tenantId": "bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb",
+        "objectId": "aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa",
+        "permissions": {
+          "keys": [
+            "get",
+            "recover",
+            "wrapKey",
+            "unwrapKey"
+          ],
+          "secrets": [],
+          "certificates": []
+        }
+      }
+    ]
+  }
+}
+```
+
+> [!NOTE] 
+> The **tenantId** and **objectId** fields must be provided with values of **identity.tenantId** and **identity.principalId** respectively from the response of managed identity for the automation account.
+
+### Change the configuration of automation account to use customer managed key
+
+Finally, you can switch your automation account from Microsft-managed keys to customer-managed keys, using the following REST API call.
+
+```http
+PATCH https://management.azure.com/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/resource-group-name/providers/Microsoft.Automation/automationAccounts/automation-account-name?api-version=2020-01-13-preview
+```
+Request body
+
+```json
+ {
+    "properties": {
+      "encryption": {
+        "keySource": "Microsoft.Keyvault",
+        "keyvaultProperties": {
+          "keyName": "sample-vault-key",
+          "keyvaultUri": "https://sample-vault-key12.vault.azure.net",
+          "keyVersion": "7c73556c521340209371eaf623cc099d"
+        }
+      }
+    }
+  }
+```
+Sample response
+
+```json
+{
+  "name": "automation-account-name",
+  "id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/resource-group-name/providers/Microsoft.Automation/automationAccounts/automation-account-name",
+  ..
+  "properties": {
+    ..
+    "encryption": {
+      "keyvaultProperties": {
+         "keyName": "sample-vault-key",
+          "keyvaultUri": "https://sample-vault-key12.vault.azure.net",
+          "keyVersion": "7c73556c521340209371eaf623cc099d"
+      },
+      "keySource": "Microsoft.Keyvault"
+    },
+    ..
+  }
+}
+```
+
+## Manage customer-managed keys lifecycle
+
+### Rotate customer-managed keys
+
+You can rotate a customer-managed key in Azure Key Vault according to your compliance policies. When the key is rotated, you must update the automation account to use the new key URI. 
+
+Rotating the key does not trigger re-encryption of secure assets in the automation account. There is no further action required from the user.
+
+### Revoke access to customer-managed keys
+
+To revoke access to customer-managed keys, use PowerShell or Azure CLI. For more information, see [Azure Key Vault PowerShell](https://docs.microsoft.com/powershell/module/az.keyvault/) or [Azure Key Vault CLI](https://docs.microsoft.com/cli/azure/keyvault). Revoking access effectively blocks access to all secure assets in the automation account, as the encryption key is inaccessible by Azure Automation.
+
+## Next steps
+
+- [What is Azure Key Vault?](../key-vault/key-vault-overview.md) 
+- [Certificate assets in Azure Automation](shared-resources/certificates.md)
+- [Credential assets in Azure Automation](shared-resources/credentials.md)
+- [Variable assets in Azure Automation](shared-resources/variables.md)