Even though you should not be using access policies anymore, sometimes there is no other option. One of the reasons is once somebody used an access policy on a Key Vault, RBAC actually breaks and you have to define everything with access policies.
While we were setting up some new access policies for applications, we noticed that we could no longer assign ‘Application-only’ policies through the portal.
The initial approach in trying to solve this was of course picking a user as well. This will result in a compound identity policy.
When we read on the docs:
Note: Application-plus-user (sometimes referred as compound identity): The user is required to access the key vault from a specific application and the application must use the on-behalf-of authentication (OBO) flow to impersonate the user. For this scenario to work, both
applicationIdandobjectIdmust be specified in the access policy. TheapplicationIdidentifies the required application and theobjectIdidentifies the user. Currently, this option isn’t available for data plane Azure RBAC.
So according to the docs, this does not only not work for the data plane (which is what you need to access actual data, or in this case secrets and keys). It would also require the application to act on behalf of the person, which you typically don’t want.
For most applications, you should be able to find them in the Principal list directly rather than looking under Application. If not, you can still fall back to the Azure CLI command:
az keyvault set-policy --name <keyvaultname> --object-id <application-objectid> --secret-permissions List Get
Note: Even though I just explained how to set access policies, please look at correctly setting up RBAC on Key Vault instead.