Azure Key Vault

Has somebody been peeking on my X-mas list?

Indeed, one of the weakness of the current Azure Paas solution I pointed out last year was that on non-trivial solutions you end up with plenty of secrets (e.g. user-name / password, SAS, account keys, etc.) stored insecurely in your web.config (or similar store).

I was suggesting, as a solution, to create a Secret Gateway between your application and a secret vault.

Essentially, Azure Key Vault fulfils the secret vault part and a part of the Secret Gateway too.

Azure Key Vault, a new Azure Service currently (as of early February 2015) in Preview mode, allows you to store keys and other secret in a vault.

One of the interesting feature of Azure Key Vault is that, as a consumer, you authenticate as an Azure Active Directory (AAD) application to access the vault and are given authorization as the application. You can therefore easily foresee scenarios where the only secret stored in your configuration is your AAD application credentials.

The vault also allows you to perform some cryptographic operation on your behalf, e.g. encrypting data using a key stored in the vault. This enables scenarios where the consuming application never knows about the encrypting keys. This is why I say that Azure Key Vault performs some functions I described for the Secret Gateway.

I see many advantages of using Azure Key Vault. Here are the ones that come on the top of my head:

I think to be air tight, the Secret Gateway would still be interesting, i.e. an agent that authenticates on your behalf and return you a token only. This way if your application is compromised, only temporary tokens are leaked, not the master keys.

But with Azure Key Vault, even if you do not have a Secret Gateway, if you compromise your master keys you can centrally rotate them (i.e. change them) without touching N applications.

I’m looking forward to see where this service is going to grow and certainly will consider it in future Paas Architecture.

Leave a comment