Feature request - Key Vault use RBAC instead of Access Policies

[o-l-a-v]

Using access policies with Key Vault is a) legacy vs. RBAC, and b) problematic with IaC.

The problem with IaC is that having accessPolicies inside the Key Vault resource in ARM or Bicep makes access policies indempotent: All other access policies are wiped. That could be worked around by creating a child resource vaults/accessPolicies after the Key Vault:

• https://codeisahighway.com/how-to-incrementally-update-keyvault-access-policies-with-arm-templates/

BUT, one can't create a Key Vault with access policies without specifying accessPolicies:

• 2018-10-17: KeyVault Schema Requires Access Policy - Docs Say It Is Not Required Azure/azure-resource-manager-schemas#521

I can't get Bicep what-if to show changes for accessPolicies either, so we're blind on changes before pushing the big deploy button.

The only logical conclusion here would be to change Key Vault to using RBAC, as far as I can see.

[bb-froggy]

Yes, agreed, we'll switch to RBAC.

I initially thought that it would be a good thing that with Access Policies, you would have that very short list of identities that can access the private key (i.e., only SCEPman), and not have many identities that inherit permissions, e.g. from the subscription or resource group. It turns out that even Owner permissions do not allow access to the actual secrets or private keys, so the inheritance is not actually a problem -- it is still only SCEPman who can access the private key, as long as nobody has specific Key Vault permissions on a superordinate organizational structure like the resource group.