There are a couple ways you can go about configuring OIDC and granting policies. However, it’s important to understand that using the default role, anybody that’s granted access to Vault via Azure will be able to log into Vault and get the policy assignments for the default role.
Depending on your requirements it may be beneficial to set token_no_default_policy on the default role.
Option 1:
Create non-default roles and use the bound_claims parameter. This will require your users to provide a role name when logging into Vault. The claims you define (e.g., group = vault-ro) must match for authentication to succeed and policy assignment to be applied.
Option 2:
Use a single role and leverage Identity Groups and Aliases for policy assignment. More info on configuring this is available in a previous forum post or the Azure OIDC provider docs. This is the method I would recommend in most cases.
A combination of the above two items is also possible.
If you’re not defining bound_claims in the role, then yes. Leveraging the Identity Groups/Aliases method mentioned above is the method I would recommend in most cases. While it’s a bit more complex to set up, it does offer a lot more flexibility and ease of use for your end users (if you’re a member of multiple groups that grant varying levels of access this will give you the cumulative set of policies across all the relevant group memberships).
However, if you want/need to enforce “personas” (suppose you have a developer that works on marketing and accounting projects but must not have access to marketing AND accounting secrets at the same time), then having the developer declare a role at login would be the way to go. This would be facilitated by using the bound_claims parameter on each role and assigning only the relevant policies for the respective roles.