7

I want to lock down my Key Vault as securely as possible. I believe access control is who can access and modify the Key Vault as a whole. Access policies are who or what can access secrets.

Our admin group should be in the access control group. Our App Service (which has a managed identity) should be in access policies. I don't think there is any need for anymore than this?

Bryan Schmiedeler
  • 2,977
  • 6
  • 35
  • 74

1 Answers1

11

Yes, you are right.

The Access control (IAM) is in management plane, the Access policies is in data plane. In your case, you should note if your admin group is just in the Access control (IAM), even if it is Owner/Contributor, the user in the group will not be able to access the secrets directly, unless the user adds himself to the Access policies.

Similarly, if you don't want the user/service principal/group to access the secrets, never add them to the Access control (IAM) as roles like e.g Owner/Contributor, because they will be able to add themselves to the Access policies.

Joy Wang
  • 39,905
  • 3
  • 30
  • 54
  • Joy, sorry I do have one follow-up question. Give my app managed identities and then add it to access policies giving it Get and List authority. Don't put users or groups in the access level even at Contributor. I do have to put the developer group into the access policies, but understand also not at Contributor level as then they could change their security. But then what security do I give them? – Bryan Schmiedeler Mar 12 '20 at 14:27
  • @BryanSchmiedeler Not sure if I understand your meaning correctly, if you have to add the group to the `Access control`, there are many [built-in roles](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles) in the management plane(Access control (IAM)), you could check if they meet your requirement. – Joy Wang Mar 12 '20 at 15:00
  • @BryanSchmiedeler If they do't meet your requirement, you could create a [custom rbac role](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles), just add the `Microsoft.KeyVault/*` in the `notActions` of the json file in this [link](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#contributor), then the custom role should not allow the users add themselves to the access policies. – Joy Wang Mar 12 '20 at 15:01
  • 1
    From April 2021, Azure Key vault supports RBAC too. So you can use Azure RBAC for control plane access (eg: Reader or Contributor roles) as well as data plane access (eg: Key Vault Secrets User). – Rohit Jun 15 '21 at 19:05
  • @Rohit Could you pls explain the RBAC Key Vault secrets user role in depth in relation with RBAC and Access Policy? – cloudcop Jul 27 '21 at 18:36
  • @cloudcop If you enable the Key vault for Azure RBAC, then you wont need key vault access policies to give permission to other users for accessing key/secret/certificate. You can use Azure RBAC instead. Eg : The role Key Vault Secrets User can allow the user to read secrets. The advantage of this approach is that permissions can be given in advance at higher levels and need not be given later right after key vault creation. But note that kv access policies dont work with RBAC enabled kv. So have to be wise in deciding what works for you. – Rohit Nov 24 '21 at 18:22
  • 1
    Great explanation. Please fix a typo: " never add them to the Access policies as roles ... " should be " never add them to the Access Control as roles ..." – S2L Feb 07 '22 at 14:54