Vault OIDC with google, how to restrict roles to specific groups

Vault
#1

I installed a vault and configured OIDC with gsuite, that was already an adventure in itself as the documentation is limited and even wrong at more than one place.

Finally I have a working authentication with my google accounts and I began to create roles, and there I saw a huge issue. How do you restrict google users from using a role. Let’s say I create a gsuite-admin role that has access to all of vault administration, any user entering the role before login can assume it.

I tried to use the different claims but those seems to be only for vault created groups or other things.

Does anyone has a solution for that?

Thank you in advance.

2 Likes
#2

I am also interested in this question!

#3

I’m also interested in this question.

#4

Yeap! I wish to know how to apply these permissions using OIDC (GSuite).

#5

Hello, @night-gold. I’m happy to help answer your questions. Please let me know which parts of the documentation you’ve found to be incorrect.

From what I’ve gathered, you’d like to prevent specific Google users from logging in with a specific role. Can you help to clarify a bit more as to how you’re trying to use G Suite groups?

One way I can think of to accomplish the behavior would be to specify bound_claims on the role. bound_claims can be used to check arbitrary claims and prevent a successful login if claims values don’t match expected values. Have you tried to use bound_claims to achieve the behavior you want?

#6

Hello,

The documentation I used is that one: vault oidc provider

For the unclear part in the documentation what was the most unclear was where to put the gsuite_service_account, I had to try multiple things until I figured out in a cluster mode you need to have the file deployed on each instances. I think the description should be “Path on all vault instances…”.

Then the example configuration and role does not work… I tried really hard to give the conf in the command line after having issues with the UI… and it was impossible to give the provider_config as in the example… An UI example may be best for this part… Same on the role example, claims could not be declared that way, I had to declare a json file and then call it with “@filename” to be able to declare claims.

I tried to use bound_claims, but when I do that even if I’m part of the group I declare in the role, I can’t get to login, it just gives an error, I tried something like that:
{
“allowed_redirect_uris”: “https://URL/ui/vault/auth/oidc/oidc/callback,http://localhost:8250/oidc/callback”,
“user_claim”: “sub”,
“policies”: “vault_admin”,
“ttl”: “24h”,
“groups_claim”: “devops”,
“oidc_scopes”: “profile”,
“bound_claims”: {
“group”: [“devops”]
}
}

So I tried that but then nobody is able to connect… We check in the Gsuite console and I’m in the group, if I remove the claim I can connect but anyone can connect using the role.

What is the right way to use the roles and Gsuite groups to limit the role?

1 Like
#7

Thanks for the feedback, @night-gold. I’ll be updating the documentation to make it clear that the service account JSON file needs to be available on each instance.

Are you able to provide an example of what didn’t work for declaring both the config and role? The examples documented at https://www.vaultproject.io/docs/auth/jwt_oidc_providers.html#configuration work for me using the Vault CLI without any issue.

In the meantime, I’m having a closer look at what we can do to allow bound_claims to be used to limit the role usage to a particular G Suite group when logging in.

#8

Hello @austingebauer , thanks for you answer.

The error was really specific to fields that contains multiple values… It was not being recognize as a map, like in this issue when following the doc.

#9

@night-gold - It appears that the bound_claims issue you’re having related to limiting the role usage to a particular G Suite group is a bug. There is currently a Github issue open for it at: https://github.com/hashicorp/vault-plugin-auth-jwt/issues/138. You can track the status of the bug from that Github issue. This is on our radar now. We’ll be working to get this fixed.