hashicorp / vault

A tool for secrets management, encryption as a service, and privileged access management
https://www.vaultproject.io/
Other
30.99k stars 4.19k forks source link

OIDC: Ability to get access privileges based on all the roles combined matching group claims #9055

Open techs07 opened 4 years ago

techs07 commented 4 years ago

Scenario: In OIDC, we can configure roles and map bound_claim to some group(s). Eg:

Role2 "bound_claims": { "custom_groups": [ "group_2"] }

There are scenarios when a user can be a member of multiple projects/teams. As a user I would like to get access privileges based on all the groups matching bound claims across all the configured roles.

Describe the solution you'd like At the time login, user should get access privileges based on the all the roles matching group claim. Example:

Roles configured in vault: Role1 : { "policies": [ "policy1"], "bound_claims": { "custom_groups": [ "group1" ] }, "groups_claim": "groups", "oidc_scopes": "groups" } Role2 : { "policies": [ "policy2" ], "bound_claims": { "custom_groups": [ "group2" ] }, "groups_claim": "groups", "oidc_scopes": "groups" }

Groups returned by OIDC provider in claim "groups" : ["group1", "group2", "groupN"]

Since there are already 2 roles configured in vault matching the groups (group1 and group2) returned in claim. User get access to based on the combined policy configured in role1 and role2 (which is policy1 and policy2).

Describe alternatives you've considered Currently we need to specify roles while logging in to vault. If a user has access access to multiple roles, he needs to login again by specifying different role which is not user friendly and efficient.

erickufrin-okta commented 4 years ago

It would be great if this capability were not limited to the OIDC plugin auth. We use Okta API auth and want this very same capability!

ghost commented 4 years ago

Any update on this enhancement??

kalafut commented 4 years ago

Hi @techs07. I think the solution you're after is doable today. Vault has identity groups (see https://www.vaultproject.io/docs/secrets/identity#identity-groups) that can be associated with one or more policies. A user in multiple groups inherits all of the policies from all of the groups. So if the groups_claim points to an accurate set of groups, and these groups are set up in Vault with the right subset of polices, the merging of permissions should be what you're looking for.

If this isn't what you're trying to achieve, can you explain the distinction?

techs07 commented 4 years ago

Hi Jim,

I have tried this solution suggested by you and Eric. But there is a major problem with that.

If I configure a default role WITHOUT bound_claims, the user inherits all of the policies from all of the groups and default role. But if any user who doesn't have another valid role, still gets access based on the default role conigured. (which I don't want, as I have configured default role, so that user can avoid writing default role at the time login).

If I configure a default role WITH bound_claims, only users with default role can login and no other roles will be allowed (unless specified at the time of login.)

Is there any way where only privileged users can login without specifying role at the login page. ?

Thanks

On Thu, Sep 24, 2020 at 8:19 PM Jim Kalafut notifications@github.com wrote:

Hi @techs07 https://github.com/techs07. I think the solution you're after is doable today. Vault has identity groups (see  https://www.vaultproject.io/docs/secrets/identity#identity-groups) that can be associated with one or more policies. A user in multiple groups inherits all of the policies from all of the groups. So if the groups_claim points to an accurate set of groups, and these groups are set up in Vault with the right subset of polices, the merging of permissions should be what you're looking for.

If this isn't what you're trying to achieve, can you explain the distinction?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/hashicorp/vault/issues/9055#issuecomment-698394166, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKK4SLDTXYUKO4EO456ZSCLSHNMBBANCNFSM4NGSAYMQ .

ghost commented 4 years ago

Scenario: Login to vault from OneLogin At vault end: Configured "vault_jwt_auth_backend" supplying default role (terraform)

created alias role binding from one login and user able to access one login with appropriate privileges but

here each policy we need to tie separately using "vault_identity_group" to vault_identity_group_alias

1) I was looking is there any possibility to write a dynamic policy which can allow users based on the roles they are attached in one login with one single policy at vault end.

2) the user shouldn't prompt to select OIDC and mount path

erickufrin-okta commented 3 years ago

We ended up getting this exact use case worked out. Exactly as the title describes.

ghost commented 3 years ago

We are achieved this too with templating in role policies, But the second one seems mandatory to select OIDC from dropdown and specifying mount path.

erickufrin-okta commented 3 years ago

We got it working using a single role. Leveraging external/aliased groups passed in the OIDC token When the user logs on they do not have to provide their role. And any groups they are in they receive additive access.

Are critical requirement for us was that they system be smart enough to autodetect and additive-access any multirole users. We achieved that. Our end users dont need to know what role(s) theyre in.

In our current structure we still have to create per group policies and link them to each group. But that is required either way.

nia-potato commented 10 months ago

@erickufrin-okta apologies for pinging you for this old issue again, but how did you achieve this with just one role with mappings of bound claims with different groups? are you using a dynamic policy instead of static one? im facing the exact same issue but was not able to piece up the config from this issue.