2

I want to create an Azure key vault with fairly restricted access (one or two of our apps). I've created the Key Vault through the Azure portal, but when I look at the Access Control section, I find that several Apps and Users have the Contributor role (inherited from the subscription) for the key vault, which gives them more access than they should have.

Since the subscription is the highest level at which access control can be set, there is no way for me to revoke access for these apps/users without revoking it at the subscription level, and this would probably cause all sorts of problems. (it's not really clear what permissions these need, so it'd be a bit painful to have to give those permissions at a resource group or resource level). What's more, there'd be nothing stopping someone who comes along later from adding contributor roles at the subscription level (for some new app, for instance), and breaking the security of the key vault.

So with all of this in mind, what would be the best way to limit access to an azure key vault, so that only the apps/users I want have access to it, despite the fact that several apps/users already have these permissions at the subscription level?

More info: We're using the Azure Resource Manager model, and everything is currently stored in one subscription.

Jacob Soderlund
  • 345
  • 1
  • 9
  • 1
    Seems you could not limit the users/apps with contributor role in subscription scope, even if use [access policy](https://learn.microsoft.com/en-us/azure/key-vault/key-vault-secure-your-key-vault#key-vault-access-policies), they also can grant the access for themselves. – Joy Wang Oct 04 '18 at 09:03

2 Answers2

2

It looks like you can not achieve this with the way RBAC works today.

Here are a couple of feedback requests already running on Feedback Forums - https://feedback.azure.com. One is for Key Vault and another takes the example of a storage account but essentially looking for the same feature to override the inherited permissions.

You may want to vote up for these requests.

  1. Deny users with inherited permissions to Azure Key Vault Service from modifying Access Policies

  2. Exclude / override RBAC permissions inhereted from a subscription at a resource group level

UPDATE (to answer additional queries from comments):

Not granting subscription-level access in the first place (except to admins)

Yes this would definitely help.

Another suggestion would be to try and use Resource Groups to organize your resources and then assign roles on these Resource Groups (scope). This way, you don't need to give access to individual items, but at the same time you can avoid giving access at the highest level of subscription.

Rohit Saigal
  • 9,317
  • 2
  • 20
  • 32
  • I'll take a look at those requests, thanks for your helpful answer. Anyway, with this still being the case, what might be a better way to set things up to deal with this issue from the start? Not granting subscription-level access in the first place (except to admins)? Or maybe something like having multiple subscriptions? – Jacob Soderlund Oct 05 '18 at 07:09
  • I would absolutely upvote it... if I had enough reputation to do so – Jacob Soderlund Oct 05 '18 at 07:44
  • no worries :) I have updated my answer to include suggestions for some of your queries. – Rohit Saigal Oct 05 '18 at 07:49
0

An option you have is to create a blueprint that you can use to configure locks on your keyvaults. If you deploy this BP as readonly the locks can't be removed from your vault so no-one can alter te permissions of your vault until you change the blueprint config again to don't lock and then remove the lock from your vault.

Applications etc having access to your vault (aka dataplane) de still access the keys ofcource

Charl Pels
  • 1