I started getting this problem today when I try to use same secret for my second application in a single key vault;
Multiple resources/entities can access a single Key Vault instance – provided they’re all in the same location (data center).
You may choose to segment your keys, secrets and certificates, either by placing them in different Key Vaults or by using different access methods/identities, however that’s not necessary.
The only time you need a separate Key Vault instance is when the resources/entities accessing it are in another location (data center/region).
It’s worth noting that you don’t need to worry too much about provisioning Disaster Recovery for resources using Key Vault, as the SLA Microsoft provide is unsurprisingly good: https://docs.microsoft.com/en-gb/azure/key-vault/key-vault-disaster-recovery-guidance. One caveat to that would be if you’re running IaaS/PaaS instances and want to run a DR fail-over yourself to another data center, at which point you’d need to manually migrate the keys/secrets/certificates in your main Key Vault into another instance (and re-point your VMs accordingly)
I am going to create and configure Azure key vault in this demo. I am assuming that an app services has already been provisioned. We need to make a configuration change for SQL connection so that Key Vault secret can be used without touching the application code.
Provision the Azure Key Vault
For this demo, I am going to use new permission model that is based on Azure role-based access control (RBAC).
I am leaving it as Public endpoint to match the App service configuration.
Click on Review + Create button to start the deployment.
Once created, add yourself to the role “Key Vault Administrator” via the Access Control (IAM). Now you can start managing secrets.
Add the connection string to the Key Vault secrets.
Secret type (Upload options) “Manual”, give it a name and set the value to the SQL Database connection string to your Azure SQL or Azure SQL VM.
Click on Create. Once created, click on the secret to see the secret details, then click again on the current version.
Copy Secret Identifier to your clipboard.
Add the Secret identifier reference to the Azure App Service Settings
Open the App Service configuration settings, and ad a new Connection string setting.
Type the name of the connection string (“SqlConnectionString” for application) and set the value. You can use the same name that you have used in appsettings.json file. Set the value;
On the App Service, click on Identity to enable the System Assigned identity. Click on save after turning “On” the status.
Click on the “Role Assignments” button and then click on the “Add role assignment”. In the role assignment, choose scope “Key Vault”, subscription the subscription where you created the Key Vault on previous steps and the name of the Key Vault resource. For the role just select “Key Vault Secrets User (preview)”
You can go to the appsettings.json/web.config file of your application and clear the connection string value;
Visit your website and see if it loads successfully. The connection string is safely stored in the Azure Key Vault, and it’s no longer stored on the file system.
Known issues
ERROR: You might get an error “Keyword not supported: ‘@microsoft.keyvault(secreturi'”. I have experienced that the RBAC permissions can take a one or two minutes to be applied, so try after a few minutes. Also try restarting the application thought the App Service portal so nothing is cached.
another error might be this;
ERROR: Format of the initialization string does not conform to specification starting at index 0.
Check your connection string. it has spaces or is not right.
