Correct approach for maintaining microservice specific secrets?

[TwinkleTShah]

Environment

• Spring boot starter:
  • key vault spring boot starter
• OS Type: Windows/Linux/MacOS
  • Linux
• Java version:
  • 1.8

Summary

We are planning to use Azure key vault to maintain DB passwords used by microservices. As per standards, the property name for DB password is "spring.datasource.password". We can store only one value with key corresponding to "spring.datasource.password" in an Azure vault. What is the correct approach for use case where different Microservices has different DB passwords? Should there be different Vault instances per Microservice? Should this spring boot starter project provide some way to handle this use case with single vault instance?

Note: DB password is just one example. The same applies to any standard spring configuration property which holds a secret and have different values per microservice.

[saragluna]

Thanks for reporting this. Since a single vault instance could not have different values for the same configuration key, it may be better to host the key in different vaults.

[TwinkleTShah]

Thanks for reply @saragluna . Do you know if it is also a recommended approach from Micorsoft Azure perspective. There might be 100s of microservices and maintaining those many vaults might be difficult. Are you aware if there are any plans to have better mechanism to handle such use cases? Like I know with Hashicorp Vault, there is a support for hierarchy where the service name could be part of hierarchy while storing the secrets and the spring boot starter project resolves the keys based on the service name.

[saragluna]

Based on your description I think Azure App Configuration could help.

[TwinkleTShah]

Hi @saragluna, As per my understanding Azure App Configuration is to manage application configurations. But it would not be correct choice for managing secrets like database passwords. If not hierarchy, can there be something like, we append the service name as prefix to the actual key and this starter project can resolve to corresponding key based on the consuming microservice. Like values in the vault are service1-key, service2-key, and if service1 is trying to resolve key, the value corresponding to service1-key is returned and if service2 is trying to resolve, the value corresponding to service2-key is returned.

[saragluna]

Yes, this could be one possible solution but for now, the key-vault-starter does not support it.

[nmiodice]

One approach, if running within the context of an app service, is to use the following syntax for your app config:

@Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/mysecret/ec96f02080254f109c51a1f14cdb1931)

Full docs here: https://docs.microsoft.com/en-us/azure/app-service/app-service-key-vault-references

[saragluna]

Closing this issue.