Azure KeyVault strategies

In web application development, one of the key security practice to take care of is not to store your secrets in safe place away from source code. So then, what we do is usually put these secrets into a KeyVault and access them on demand. But then, what happens when we have many applications each having a couple of secrets to store? What happens when each of those applications are setup in different environments? We can easily find ourselves in a mess. In this article I will discuss some Azure KeyVault strategies on how to organize them and better manage application secrets.

How to organize the KeyVaults?

As soon as we decide to use a key vault, we’ll ask ourselves, how do we organize them. Do we put everything into one vault, separate vaults, what are the recommended best practices.

There are actually many potential strategies to solve this problem. The strategy you’ll choose will be highly influenced by your organization and team setup in my opinion.

Let us discuss some potential strategies to organize your Azure KeyVaults.

One KeyVault per application/environment

One of the most recommended strategies is to use one KeyVault per application environment. This would allow us to segregate the privileges on who can see which secrets. For example, maybe the developers are allowed to see Dev environment secrets, but only the seniors can see the Quality environment secrets and only the operations team can see the Production environment secrets.

With this strategy, access to secrets can be kept to minimum and fine grained. But, this approach also comes with a downside. If you have a DevOps team responsible for all environments and several applications, this does not scale well, as you’ll end up giving access everyone to every KeyVault and this will increase the proper management overhead.

On the other side, this approach works well though if the teams managing applications environments are different, e.g. if you have a dedicated operations department only for Production environment.

One KeyVault per Application

Another possible approach is to put all application secrets for all environments into one KeyVault. This would bring down the number of necessary vaults but it would also allow everyone to see all secrets. Also, you’ll need to come up with a proper naming structure to easily differentiate environment specific secrets.

If this is not clashing with your security policies, this could work well if you have DevOps teams responsible for all environments. One big downside of this approach to mention is, it is susceptible of unintentional accidental changes, e.g. when someone was intending to change the Dev environment connection string but accidentally changes the Production environment secret.

One KeyVault per team

While this is maybe the approach with the least KeyVault access management effort requirements, I think this works contrary for secret management. Having all secrets in one KeyVault will make secret management very difficult if the team is managing more than one application. It also makes it very easy for a team member to delete or change an unintended secrets and have unintended side effects on other applications.

I would recommend to avoid this strategy if possible.

Conclusion

When evaluating the KeyVault strategy, I would take into consideration these factors:

  • Security requirements
  • Organizational requirements
  • Access management effort

Based on these criteria, you should determine which strategy will give you a good enough security level (although, there is never enough security ;)) and management access management overhead. I hope these Azure KeyVault strategies give you some hints in deciding what works well for your case.