Merge pull request #52968 from MicrosoftDocs/UPDATE-manage-secrets-with-azure-key-vault

Remove sandbox from manage-secrets-with-azure-key-vault

Author: JamesJBarnett

learn-pr/azure/manage-secrets-with-azure-key-vault/3-creating-vaults-storing-secrets.yml

@@ -8,8 +8,8 @@ metadata:
   author: msmbaldwin
   ms.author: mbaldwin
   ms.topic: unit
-interactive: bash
-azureSandbox: true
+#interactive: bash
+#azureSandbox: true
 durationInMinutes: 7
 content: |
   [!include[](includes/3-creating-vaults-storing-secrets.md)]

learn-pr/azure/manage-secrets-with-azure-key-vault/5-access-secrets-from-web-app.yml

@@ -13,8 +13,8 @@ metadata:
     - devx-track-js
   zone_pivot_groups: dev-lang-csharp-javascript
 durationInMinutes: 13
-interactive: bash
-azureSandbox: true
+#interactive: bash
+#azureSandbox: true
 content: |
   [!include[](includes/5-access-secrets-from-web-app.md)]
 

learn-pr/azure/manage-secrets-with-azure-key-vault/6-configure-deploy-run-azure.yml

@@ -14,8 +14,8 @@ metadata:
     - devx-track-js
   zone_pivot_groups: dev-lang-csharp-javascript
 durationInMinutes: 12
-interactive: bash
-azureSandbox: true
+#interactive: bash
+#azureSandbox: true
 content: |
   [!include[](includes/6-configure-deploy-run-azure.md)]
 # NOTE: Task validation is failing for learners, so that is disabled for now.

learn-pr/azure/manage-secrets-with-azure-key-vault/includes/1-introduction.md

@@ -1,22 +1,22 @@
-If you want to understand what can go wrong with managing an app's configuration secrets, look no further than the story of Steve, a senior developer.
-
-Steve was working at a pet food delivery company for a few weeks. While exploring the details of the company's web app—a .NET Core web app that used an Azure SQL database for storing order information and third-party APIs for credit card billing and mapping customer addresses—Steve accidentally pasted the connection string for the orders database into a public forum.
-
-Days later, the accounting department noticed that the company was delivering a substantial amount of pet food that wasn't paid for. Someone used the connection string to access the database and create orders by updating the database directly.
-
-After Steve realized his mistake, he hurriedly changed the database password to lock out the attacker. After Steve changed the password, the website started returning errors to users. The app server needed an updated configuration with the new password. Steve logged directly into the app server and changed the app configuration instead of redeploying, but the server was still showing failed requests.
-
-Steve forgot that multiple instances of the app ran on different servers. He only changed the configuration for one. A full redeployment was needed, causing another 30 minutes of downtime.
-
-Fortunately for Steve, the accounting department was able to correct the errors quickly, and only one day's worth of orders were affected. Steve might not be so lucky in the future, though, and needs to find a way to improve the security and maintainability of the app.
-
-If a database connection string, API key, or service password is leaked, it can be catastrophic. A leak could potentially lead to stolen or deleted data, financial harm, app downtime, and irreparable damage to business assets and reputation. Unfortunately, secret values often need to be deployed in multiple places simultaneously and changed at inopportune times. And you have to store them *somewhere*! See how Steve can reduce risk and improve the security and maintainability of his app with Azure Key Vault.
-
-## Learning objectives
-
-In this module, you will:
-
-- Explore what types of information can be stored in Azure Key Vault.
-- Create an Azure Key Vault and use it to store secret configuration values.
-- Enable secure access to the Azure Key Vault from an Azure App Service web app with managed identities for Azure resources.
-- Implement a web app that retrieves secrets from the Azure Key Vault.
+If you want to understand what can go wrong with managing an app's configuration secrets, look no further than the story of Steve, a senior developer.
+
+Steve was working at a pet food delivery company for a few weeks. While exploring the details of the company's web app—a .NET Core web app that used an Azure SQL database for storing order information and third-party APIs for credit card billing and mapping customer addresses—Steve accidentally pasted the connection string for the orders database into a public forum.
+
+Days later, the accounting department noticed that the company was delivering a substantial amount of pet food that wasn't paid for. Someone used the connection string to access the database and create orders by updating the database directly.
+
+After Steve realized his mistake, he hurriedly changed the database password to lock out the attacker. After Steve changed the password, the website started returning errors to users. The app server needed an updated configuration with the new password. Steve logged directly into the app server and changed the app configuration instead of redeploying, but the server was still showing failed requests.
+
+Steve forgot that multiple instances of the app ran on different servers. He only changed the configuration for one. A full redeployment was needed, causing another 30 minutes of downtime.
+
+Fortunately for Steve, the accounting department was able to correct the errors quickly, and only one day's worth of orders were affected. Steve might not be so lucky in the future, though, and needs to find a way to improve the security and maintainability of the app.
+
+If a database connection string, API key, or service password is leaked, it can be catastrophic. A leak could potentially lead to stolen or deleted data, financial harm, app downtime, and irreparable damage to business assets and reputation. Unfortunately, secret values often need to be deployed in multiple places simultaneously and changed at inopportune times. And you have to store them *somewhere*! See how Steve can reduce risk and improve the security and maintainability of his app with Azure Key Vault.
+
+## Learning objectives
+
+In this module, you will:
+
+- Explore what types of information can be stored in Azure Key Vault.
+- Create an Azure Key Vault and use it to store secret configuration values.
+- Enable secure access to the Azure Key Vault from an Azure App Service web app with managed identities for Azure resources.
+- Implement a web app that retrieves secrets from the Azure Key Vault.

learn-pr/azure/manage-secrets-with-azure-key-vault/includes/2-what-is-key-vault.md

@@ -1,40 +1,40 @@
-Azure Key Vault is a *secret store*: a centralized cloud service for storing app secrets, such as configuration values like passwords and connection strings that must always remain secure. Key Vault helps you control your apps' secrets by keeping them in a single central location. It provides secure access, permissions control, and access logging.
-
-> [!VIDEO https://learn-video.azurefd.net/vod/player?id=0bfd13a0-a16b-4191-9c56-fcfb3bd63247]
-
-The main benefits of using Key Vault are:
-
-- Separation of sensitive app information from other configuration and code, which reduces the risk of accidental leaks.
-- Restricted secret access with access policies tailored to the apps and individuals that need them.
-- Centralized secret storage, meaning required changes only have to be made in one place.
-- Access logging and monitoring to help you understand how and when secrets are accessed.
-
-Secrets are stored in individual *vaults*, which are Azure resources used to group secrets together. Secret access and vault management is accomplished by using a REST API. All of the Azure management tools and client libraries available for many popular languages also support this API. Every vault has a unique URL where its API is hosted.
-
-> [!IMPORTANT]
-> *Key Vault is designed to store configuration secrets for server apps.* It's not intended for storing data belonging to your app's users. It shouldn't be used in the client-side part of an app. This behavior is reflected in its performance characteristics, API, and cost model.
->
-> User data should be stored elsewhere, such as in an Azure SQL database with Transparent Data Encryption, or a storage account with Storage Service Encryption. Secrets your app uses to access those data stores can be kept in Key Vault.
-
-## What is a secret in Key Vault?
-
-In Key Vault, a secret is a name-value pair of strings. Secret names must be 1-127 characters long, contain only alphanumeric characters and dashes, and must be unique within a vault. A secret value can be any UTF-8 string up to 25 KB in size.
-
-> [!TIP]
-> Secret names don't need to be considered especially secret themselves. You can store them in your app's configuration if your implementation calls for it. The same is true of vault names and URLs.
-
-> [!NOTE]
-> Key Vault supports two additional kinds of secrets beyond strings: *keys* and *certificates*. Key Vault provides useful functionality specific to their use cases. This module does not cover these features and concentrates on secret strings like passwords and connection strings.
-
-## Vault authentication and permissions
-
-Key Vault's API uses Microsoft Entra ID to authenticate users and apps. Vault access policies are based on *actions* and are applied across an entire vault. For example, an app with `Get` (read secret values), `List` (list names of all secrets), and `Set` (create or update secret values) permissions to a vault can create secrets, list all secret names, and get and set all secret values in that vault.
-
-*All* actions performed on a vault require authentication and authorization. There's no way to grant any kind of anonymous access.
-
-> [!TIP]
-> When you grant vault access to developers and apps, grant only the minimum set of permissions needed. Permissions restrictions help avoid accidents caused by code bugs, and reduce the impact of stolen credentials or malicious code injected into your app.
-
-Usually, developers only need `Get` and `List` permissions to a development-environment vault. Some engineers need full permissions to change and add secrets, when necessary.
-
-For apps, often only `Get` permissions are required. Some apps might require `List` depending on the way the app is implemented. The app in this module's exercise requires the `List` permission because of the technique it uses to read secrets from the vault.
+Azure Key Vault is a *secret store*: a centralized cloud service for storing app secrets, such as configuration values like passwords and connection strings that must always remain secure. Key Vault helps you control your apps' secrets by keeping them in a single central location. It provides secure access, permissions control, and access logging.
+
+> [!VIDEO https://learn-video.azurefd.net/vod/player?id=0bfd13a0-a16b-4191-9c56-fcfb3bd63247]
+
+The main benefits of using Key Vault are:
+
+- Separation of sensitive app information from other configuration and code, which reduces the risk of accidental leaks.
+- Restricted secret access with access policies tailored to the apps and individuals that need them.
+- Centralized secret storage, meaning required changes only have to be made in one place.
+- Access logging and monitoring to help you understand how and when secrets are accessed.
+
+Secrets are stored in individual *vaults*, which are Azure resources used to group secrets together. Secret access and vault management is accomplished by using a REST API. All of the Azure management tools and client libraries available for many popular languages also support this API. Every vault has a unique URL where its API is hosted.
+
+> [!IMPORTANT]
+> *Key Vault is designed to store configuration secrets for server apps.* It's not intended for storing data belonging to your app's users. It shouldn't be used in the client-side part of an app. This behavior is reflected in its performance characteristics, API, and cost model.
+>
+> User data should be stored elsewhere, such as in an Azure SQL database with Transparent Data Encryption, or a storage account with Storage Service Encryption. Secrets your app uses to access those data stores can be kept in Key Vault.
+
+## What is a secret in Key Vault?
+
+In Key Vault, a secret is a name-value pair of strings. Secret names must be 1-127 characters long, contain only alphanumeric characters and dashes, and must be unique within a vault. A secret value can be any UTF-8 string up to 25 KB in size.
+
+> [!TIP]
+> Secret names don't need to be considered especially secret themselves. You can store them in your app's configuration if your implementation calls for it. The same is true of vault names and URLs.
+
+> [!NOTE]
+> Key Vault supports two additional kinds of secrets beyond strings: *keys* and *certificates*. Key Vault provides useful functionality specific to their use cases. This module does not cover these features and concentrates on secret strings like passwords and connection strings.
+
+## Vault authentication and permissions
+
+Key Vault's API uses Microsoft Entra ID to authenticate users and apps. Vault access policies are based on *actions* and are applied across an entire vault. For example, an app with `Get` (read secret values), `List` (list names of all secrets), and `Set` (create or update secret values) permissions to a vault can create secrets, list all secret names, and get and set all secret values in that vault.
+
+*All* actions performed on a vault require authentication and authorization. There's no way to grant any kind of anonymous access.
+
+> [!TIP]
+> When you grant vault access to developers and apps, grant only the minimum set of permissions needed. Permissions restrictions help avoid accidents caused by code bugs, and reduce the impact of stolen credentials or malicious code injected into your app.
+
+Usually, developers only need `Get` and `List` permissions to a development-environment vault. Some engineers need full permissions to change and add secrets, when necessary.
+
+For apps, often only `Get` permissions are required. Some apps might require `List` depending on the way the app is implemented. The app in this module's exercise requires the `List` permission because of the technique it uses to read secrets from the vault.

learn-pr/azure/manage-secrets-with-azure-key-vault/includes/3-creating-vaults-storing-secrets.md

@@ -1,45 +1,49 @@
-## Create Key Vaults for your applications
-
-A best practice is to create a separate vault for each deployment environment of each of your applications, such as development, test, and production. You can use a single vault to store secrets for multiple apps and environments, but the impact of an attacker gaining read access to a vault increases with the number of secrets in the vault.
-
-> [!TIP]
-> If you use the same names for secrets across different environments for an application, the only environment-specific configuration you need to change in your app is the vault URL.
-
-Creating a vault requires no initial configuration. Your user identity is automatically granted the full set of secret management permissions. You can start adding secrets immediately. After you have a vault, you can add and manage secrets from any Azure administrative interface, including the Azure portal, the Azure CLI, and Azure PowerShell. When you set up your application to use the vault, you need to assign the correct permissions to it, as described in the next unit.
-
-## Create the Key vault and store the secret in it
-
-Given all the trouble the company's been having with application secrets. Management asks you to create a small starter app to set the other developers on the right path. The app needs to demonstrate best practices for managing secrets as simply and securely as possible.
-
-To start, create a vault and store one secret in it.
-
-### Create the Key Vault
-
-*Key Vault names must be globally unique, so pick a unique name*. Vault names must be 3-24 characters long and contain only alphanumeric characters and dashes. Make a note of the vault name you choose, because you need it throughout this exercise.
-
-To create your vault, run the following command in Azure Cloud Shell. Make sure to enter your unique vault name to the `--name` parameter.
-
-```azurecli
-az keyvault create \
-    --resource-group "<rgn>[sandbox resource group name]</rgn>" \
-    --location centralus \
-    --name <your-unique-vault-name>
-```
-
-When it finishes, you see JSON output describing the new vault.
-
-> [!TIP]
-> The command used the pre-created resource group named **<rgn>[sandbox Resource Group]</rgn>**. When working with your own subscription, you would want to either create a new resource group or use an existing one you previously created.
-
-### Add the secret
-
-Now, add the secret. Our secret is named `SecretPassword` with a value of `reindeer_flotilla`. Make sure to replace `<your-unique-vault-name>` with the vault name you created in the `--vault-name` parameter.
-
-```azurecli
-az keyvault secret set \
-    --name SecretPassword \
-    --value reindeer_flotilla \
-    --vault-name <your-unique-vault-name>
-```
-
-Before you write the code for your app, you first need to learn a bit about how your app is going to authenticate to a vault.
+[!INCLUDE[](../../../includes/azure-optional-exercise-subscription-note.md)]
+
+[!INCLUDE[](../../../includes/azure-optional-exercise-create-resource-group-note.md)]
+
+## Create Key Vaults for your applications
+
+A best practice is to create a separate vault for each deployment environment of each of your applications, such as development, test, and production. You can use a single vault to store secrets for multiple apps and environments, but the impact of an attacker gaining read access to a vault increases with the number of secrets in the vault.
+
+> [!TIP]
+> If you use the same names for secrets across different environments for an application, the only environment-specific configuration you need to change in your app is the vault URL.
+
+Creating a vault requires no initial configuration. Your user identity is automatically granted the full set of secret management permissions. You can start adding secrets immediately. After you have a vault, you can add and manage secrets from any Azure administrative interface, including the Azure portal, the Azure CLI, and Azure PowerShell. When you set up your application to use the vault, you need to assign the correct permissions to it, as described in the next unit.
+
+## Create the Key vault and store the secret in it
+
+Given all the trouble the company's been having with application secrets. Management asks you to create a small starter app to set the other developers on the right path. The app needs to demonstrate best practices for managing secrets as simply and securely as possible.
+
+To start, create a vault and store one secret in it.
+
+### Create the Key Vault
+
+*Key Vault names must be globally unique, so pick a unique name*. Vault names must be 3-24 characters long and contain only alphanumeric characters and dashes. Make a note of the vault name you choose, because you need it throughout this exercise.
+
+To create your vault, run the following command in Azure Cloud Shell. Make sure to enter your unique vault name to the `--name` parameter.
+
+```azurecli
+az keyvault create \
+    --resource-group <your-resource-group-name> \
+    --location centralus \
+    --name <your-unique-vault-name>
+```
+
+When it finishes, you see JSON output describing the new vault.
+
+> [!TIP]
+> The command used the pre-created resource group named **<rgn>[sandbox Resource Group]</rgn>**. When working with your own subscription, you would want to either create a new resource group or use an existing one you previously created.
+
+### Add the secret
+
+Now, add the secret. Our secret is named `SecretPassword` with a value of `reindeer_flotilla`. Make sure to replace `<your-unique-vault-name>` with the vault name you created in the `--vault-name` parameter.
+
+```azurecli
+az keyvault secret set \
+    --name SecretPassword \
+    --value reindeer_flotilla \
+    --vault-name <your-unique-vault-name>
+```
+
+Before you write the code for your app, you first need to learn a bit about how your app is going to authenticate to a vault.