Recently I spent a couple of hours struggling with one of our Azure Key Vaults - its access policies to be more specific. Short story - I was unable to create a new one from the portal, nor access secrets or keys. After exchanging several emails with Microsoft and few calls with their technician, we managed to find both a quick solution and the root of all evil - invalid ARM template.
Key Vaults are somehow fragile resources when it comes to determining who can access them. You can be a "superadmin hero", still if a Key Vault was created in the other tenant or for an object not related with you, you can see it, you can manage it but if it comes to retrieving keys or secrets, you won't be able to do so. It's perfectly fine - it should be as secure as possible - but the way it informs you, that something is wrong, can be described as... well, lacking.
Consider following example:
It is possible with ARM to create a key vault, which can be accessed e.g. by a group of admins(by passing correct tenantId and objectId). However, let's say you have made a mistake in those fields. Key vault will still be created with an access policy, but following things will happen also:
- you won't be able to create a new access policy
- you won't be able to browse keys
- you won't be able to browse secrets
- ARM will still be able to retrieve keys and secrets
Trying to add a new policy will result in "Invalid parameter name 'accessPolicy'" error while managing it with Azure Powershell CLI will give "401 Unauthorized" response. I've seen more descriptive messages in my life TBH.
Microsoft guided me to the solution with their article Change a key vault tenant ID after a subscription move, which describes a solution suitable also if a subscription hasn't been moved and a key vault has just been created(for a invalid tenant or an object). Performing steps from the article helped me in restoring proper access to the key vault and finally led to the proper solution of our issue.