1
votes

Any one who can hack into my code and get the client id, tenant id and cert thumbprint can access the secrets stored in my key vault. So what’s the difference between this and just storing the secret values directly in my code where any one who hacks into my code could read?

2

2 Answers

0
votes

Even if someone was able to get that info, your vault will still be secure because in order to access your Key Vault and view the contents inside, a user, app, or identity will need to be added to your Key Vault's management plane (RBAC), and data plane (access policies) to view anything within your vault.

Therefore, if a user has a TenantID they still won't have access to your AKV unless they have the credentials of a user, app, or identity that has the correct RBAC and access policies permissions.

For more info: Management plane and Azure RBAC Data plane and access policies

0
votes

For applications hosted in Azure, using Managed Identity is preferred. This is a separate principal where a password is never made available to even steal or leak.

If you use the DefualtAzureCredential in the Azure SDKs, you can better configure your vault for development and production environments. You can give limited permissions to AAD users, who can log in via Visual Studio, Azure CLI, Az PowerShell Module, and more. Without modifying the code, your application can rely on Managed Identity with its own set of permissions. For example, maybe you use different vaults for production and development configured by a setting where Managed Identity has read access to secrets/keys, but your devs don't - not in the production vault. Role-based Access Control is also coming to Managed HSM (a more secure hardware-based Key Vault) to have principal granularity even in the same vault.

Service principals using environment variables can be used in lieu of Managed Identity but should be reserved only for your production environment, ideally. Devs could also have one, but that probably means sharing of client IDs and secrets, which provides little to no mitigation if someone leaves or information is leaked - no easy mitigation, anyway.