Azure Key Vault Access Policy Doesn't Work For Groups

Question

Access policies via groups on Azure Key Vault don't seem to work.

If I create a new key vault

 New-AzureRmKeyVault -VaultName $vaultName

And check the keys (which there aren't any of currently)

 Get-AzureKeyVaultKey -VaultName $vaultName

That works.

If I add access to a group that the current user is a member of

$group = (Get-AzureRmADGroup -SearchString 'All Developers')[0].Id
Set-AzureRmKeyVaultAccessPolicy -VaultName $vaultName -ResourceGroupName $resourceGroupName -ObjectId $group -PermissionsToKeys all -PermissionsToSecrets all

And remove direct access

Remove-AzureRmKeyVaultAccessPolicy -VaultName $vaultName -ResourceGroupName $resourceGroupName -UserPrincipalName $upn

The list operation now fails

Get-AzureRmKeyVault -VaultName $vaultName -ResourceGroupName $resourceGroupName

Get-AzureKeyVaultKey : Operation "list" is not allowed

How can I permission by group?

This related documentation may be helpful: https://learn.microsoft.com/en-us/azure/key-vault/key-vault-group-permissions-for-apps Though also see this issue I raised with it: https://github.com/MicrosoftDocs/azure-docs/issues/9729 — Tom Robinson, Jun 05 '18 at 13:44

score 5 · Answer 1 · answered Feb 25 '16 at 13:15

I discovered today that it works for users in permissioned group objects. Doesn't work for service principals in those groups.

In other words, if I authenticate using a client id and client secret, the associated service principal must have an access policy directly set on the key vault. If I permission a security group, a user in that group can in fact access the key vault. I guess this has something to do with how the JWT includes security groups in it with users, but not service principals...

score 4 · Answer 2 · answered Feb 24 '16 at 01:48

4

The reason that adding an access policy to a group is that it isn't supported. If you look at the help for Set-AzureRmKeyVaultAccessPolicy there is this for ObjectId

-ObjectId <Guid>
    Specifies the object ID of the user or service principal in Azure Active Directory for which to grant permissions.

    Required?                    true
    Position?                    named
    Default value                none
    Accept pipeline input?       true(ByPropertyName)
    Accept wildcard characters?  false

As you can see ObjectId only supports either Service principals or users.

This is reflected in the parameters of the source code for Set-AzureRmKeyVaultAccessPolicy and further up the chain the REST API when posting to

    https://management.azure.com/subscriptions/{subscription-id}/resourceGroups/{resource-group-name}/providers/Microsoft.KeyVault/vaults/{vault-name}?api-version={api-version}

The payload contains the objectId parameter which is defined as

Specifies the object ID of a user or service principal in the Azure Active Directory tenant for the vault. The ID must be specified as a GUID.

I would imagine that this functionality will be added at some point in future, but at the moment it isn't possible.

answered Feb 24 '16 at 01:48

Michael B

11,887
6
38
74

But there are a maximum of 10 access policies that can be put on a single key vault. So the limitation is basically that key vaults are unusable for more than 10 unique users? I just want to make sure I understand before concluding that Azure key vault is completely useless for my purposes – Jeff Feb 24 '16 at 01:53
@Jeff My personal solution to that has been to have a single Key Vault per application. On both SKUs they are cheap enough to be irrelevant. I usually deploy a vault with the rest of a resource group and lock down its permissions solely to that one app. – Michael B Feb 24 '16 at 02:09
That would be nice...but for testing purposes, I need real users to have access to the key vault...and I'm not comfortable passing around client secrets. – Jeff Feb 24 '16 at 11:57
@Jeff Could you write a new question about it? what you're looking to achieve and I'll have a think see if anything springs to mind – Michael B Feb 24 '16 at 11:59
2

Your answer is actually incorrect. I discovered today that it works for users in permissioned group objects. Doesn't work for service principals in those groups. – Jeff Feb 25 '16 at 04:14
2

Groups can now be assigned to Key Vaults, though the documentation hasn't yet been updated. :) – Philippe Signoret Mar 02 '16 at 21:09
1

0 down vote One updated piece of documentation that now shows granting permissions to a security group is example 6 here: [link](https://msdn.microsoft.com/en-us/library/mt603625.aspx) – sandshadow Jun 07 '16 at 15:32
executed according to the documentation mentioned by @sandshadow but still didn't work for us. – Reinard Dec 22 '21 at 11:21

score 0 · Answer 3 · answered Mar 09 '21 at 07:20

This Access Denied / 403 Forbidden error can also happen when an app has made requests to a Key Vault before it was added to the Azure Active Directory Group.

Perhaps this has something to do with caching of service principal information on the App Service instance? I was unable to find documentation of this.

Solution: restart the App Service.

Azure Key Vault Access Policy Doesn't Work For Groups

3 Answers3