Azure Key Vault is an Azure packaged service allowing you to encrypt keys and small secrets (e.g. passwords, SAS) and manage them in a secure fashion. Azure Key Vault actually allows you to store cryptographic keys and do operations with them (e.g. encrypt data) without revealing the key, which is pretty cool. Check it out.
A typical problem with those new services is the lack of documentation. Well, no more for the Key Vault, thanks to Dan Plastina step by step guide on Key vault. It’s succinct, straight to the point and well written.
The guide’s backbone is the vault’s lifecycle:
The typical ones I would see are:
- Secret owner creates a bunch of secrets for SAS (e.g. storage accounts, Service Bus) and allows some applications to have access to them
- Application access those secrets via REST API
- Those secrets are refreshed directly in the vault by the secret owner
- Secrets can be refreshed on Schedule by a web job
- e.g. using a storage account key, itself another secret refreshed manually (or by another process), the web job recreates SAS valid for 40 days every 30 days
- Auditor can check that access is conform to establish design
This is so much cleaner than what I see today in the field where SAS are created, put in web.config, forgotten there until they expire and shared between developers who troubleshoot problems in production, etc. . Because of the work involved trying to cycle the SAS, those SAS are usually created with multi-years validity, so if they get compromised, well, you get the picture.
The nice thing here is that the vault is doing more than protecting secrets: it allows you to manage them centrally. For me that is half the value. Especially if you have an application park bigger than 2 apps sharing some secrets. It gives you a visibility of which secrets are used by whom and allows you to manage them. You do not need to have SAS that last for 5 years anymore since you can cycle them centrally.