Per-secret/key/certificate access control
Currently it's an all or nothing model. To grant a user account or app id access to one secret, you have to grant it access to the entire vault (as far as I can tell). This eliminates the possibility of least privilege access to secrets. In this model, the only way to create security boundaries for individual secrets is to create additional key vaults, which could get out of control fast if we need one key vault per application per environment. A better model would be to have independent access controls on both the vault and the individual secrets.
For example, in the SQL Server EKM scenario, I would want to create specific asymmetric keys for each SQL Server instance and grant each instance access only to the key or keys it needs (there might be more than one for local TDE, local backups, AlwaysOn, and clustered instances). In this scenario, I (as the vault admin) don't actually even need access to the key. I just need access to create the key and grant access to the target identity of the SQL Server instance. This way, my app team can have a single key vault for many purposes with the keys locked down to the individual identities that need them.
Not just for apps, but also for functional account passwords as well. You have Server Admins, DBAs, developers, etc and obviously the developers should not need access to the admin's passwords.They should make key vault like storage accounts where you can set up containers and then use RBAC on each key vault container so you don't have to create multiple key vaults (1 per role)
I just noticed this post was created back in 2017 and they still haven't added this ability yet...smh
Bruno Brito da Silva commented
I am looking for this feature too.
Adminravijan (N/A, Microsoft Azure) commented
We are looking at this very closely and the design is under review.
Joon du Randt commented
I am building a public / hybrid PaaS based environment for use at a Fortune 100 company and the lack of per-secret access control means that I have to provision a lot more keyvaults than I would like...
Greg Lloyd commented
Totally concur, right now we having to investigate a 3rd party IaaS solution in order to get functionality of this kind. This is a major pain point since we are trying to move to a completely PaaS footprint.
Per Rosenlind commented
Agreed. Would be great to have this functionality.
I totally agree.
We are struggling with the technical limitations on the service. We need to be able to share keys instead of creating more vaults, duplicating keys etc.
Working close to teams, this is a very appriciate featur.
Agree totally. This is not a good security model need layer to manage access control
What about having containers/groups that contain multiple secrets/keys/certs that can have Access Policies applied as well. I'm considering the issue of having to apply permissions to each individual key when some require the exact same perms.
This is critical - I don't want to have to a key vault per client in our SaaS
John S commented
Allow for grouping of secrets / keys and certificates and apply permissions for that also.
without it then Key Vault is a bit contradictory
Adam Mudge commented
I agree this is needed!
Patrick van Ek commented
I would really like to see this feature as well.
As a workarround I'm making multiple keyvaults for the independent access controls, it works but it's a big hassle for operations and I'd rather see this incorporated in keyvault itself.
Jamie Pearson commented
Lack of this feature really makes Key Vault useless and limits our ability to build out a SaaS solution on Azure.
Ian Moroney commented
This is critical for a secure implementation. I can't believe that a security focused tool like the AKV would allow this type of access by default.
[Deleted User] commented
Lack of this implementation is so sad...
Totally agree. Right now it is like change a car (new KeyVault) when ashtray is full (separate team wants to use sets of secrets for their project)