Being very new to Vault and Azure AD both the systems, I want to authenticate vault using Azure AD users. Sharing any document or videos which can be followed will help me.
My requirement: I want to have two groups readonly & readwrite. An AD user who login to Vault should get the permission assigned to his group.
I tried the OIDC which is working for me but it requires a role to be defined which is not what is expected.
My Vault is: v1.8.x running as container in cloud K8S environment.
I followed this link “Azure Active Directory with OIDC Auth Method and External Groups | Vault | HashiCorp Developer” (was told that Azure UI login is not supported yet, OIDC is the only available option) and able to login with my email id, getting defined permission mentioned in my Policy and default role attached to.
It seems that 50% of my work is done. The only thing pending is how to two groups having different users and permission at AD side will be mapped at Vault side.
- If I attached two policies one as readonly and second as readwrite to the default role how permission will work without associating that to somewhere?
- I created two different roles and policy attached to them which is working if I enter that role name while login at OIDC UI, but anyone who will know the role name can login, is this expected?
Please correct me if wrong and guide me to move ahead.
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.
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.
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.
Your suggestion helped me. It’s working.