Previous

Next

Summary

Completed

In this module, you secured an app's secret configuration in Azure Key Vault. Your app code authenticated to the vault with a managed identity, and automatically loaded the secrets from the vault into memory at startup.

Clean up

The sandbox automatically cleans up your resources when you're finished with this module.

When you're working in your own subscription, it's a good idea at the end of a project to identify whether you still need the resources you created. Resources that you leave running can cost you money. You can delete resources individually or delete the resource group to delete the entire set of resources.

To clean up your Cloud Shell storage, delete the KeyVaultDemoApp directory.

Next steps

If this app was a real app, what would come next?

• Put all your app secrets in your vaults! There's no longer any reason to have them in configuration files.
• Continue to develop the app. Your production environment is all set up, so you don't need to repeat all the setup for future deployments.
• To support development, create a development-environment vault that contains secrets with the same names but different values. Grant permissions to the development team and configure the vault name in the app's development-environment configuration file. Configuration depends on your implementation: for ASP.NET Core, AddAzureKeyVault automatically detects local installations of Visual Studio and the Azure CLI and use Azure credentials configured in those apps to sign in and access the vault. For Node.js, you can create a development-environment service principal with permissions to the vault and have the app authenticate using loginWithServicePrincipalSecret.
• Create more environments for purposes like user acceptance testing.
• Separate vaults across different subscriptions and resource groups to isolate them.
• Grant access to other environment vaults to the appropriate people.

Further reading

• Key Vault documentation
• More about AddAzureKeyVault and its advanced options
• This tutorial walks through using a Key Vault SecretClient, including manually authenticating it to Microsoft Entra ID using a client secret instead of using a managed identity.
• Managed identities for Azure resources token service documentation for implementing the authentication workflow yourself.

Check your knowledge

1.

Which of the following is not a benefit of Azure Key Vault?

Secure storage of private user information.

Synchronizing application secrets among multiple instances of an application.

Reducing the need for application developers to directly handle application secrets.

Controlling access to application secrets with assignable permissions.

2.

Which of these statements best describes Azure Key Vault's authentication and authorization process?

Applications authenticate to a vault with the username and password of the lead developer and have full access to all secrets in the vault.

Applications and users authenticate to a vault with a Microsoft account and are authorized to access specific secrets.

Applications and users authenticate to a vault with their Microsoft Entra identities and are authorized to perform actions on all secrets in the vault.

Applications authenticate to a vault with the username and password of a user that signs in to the web app, and is granted access to secrets owned by that user.

3.

How does Azure Key Vault help protect your secrets after they have been loaded by your app?

Azure Key Vault automatically generates a new secret after every use.

The Azure Key Vault client library protects regions of memory used by your application to prevent accidental secret exposure.

Azure Key Vault double-encrypts secrets, requiring your app to decrypt them locally every time they're used.

It doesn't protect your secrets. Secrets are unprotected once they're loaded by your application.

You must answer all questions before checking your work.

Continue