Storing, for example, a database connection string which include server name, user id and password in source code or in a configuration file is what is called ‘password leaking’. That means that anyone who has access to application source code can search through and get access to the database, because the information required to connect is stored within it.
The same is true for any secret which you use to protect or restrict access to a secure resource.
A nice Azure feature that makes sharing secrets (ex: a database connection string) is by creating a secret within an Azure Key Vault. A single Azure Key Vault can have many secrets.
Start by creating the Azure Key Vault as seen in Figure 1.
Figure 1, how to create an Azure Key Vault
After its creation, create a Secret by clicking the Secrets link and then Generate/Import as seen in Figure 2.
Figure 2, create an Azure Key Vault Secret
Then create the Secret Name and value, as seen in Figure 3
Figure 3, create an Azure Key Vault Secret Name and Value
There are numerous ways to then access the Secret from code. I prefer using Access Policies and a Managed Service Identity which I discussed here:
- Using Managed Service Identity MSI with and Azure App Service or an Azure Function
- How to connect to a database from an Azure Function using Azure Keys Vault
You might also find these articles helpful as well:
- Get started with Azure Key Vault
- Configure an Azure web application to read a secret from Key Vault
- Azure Key Vault – Step by Step