feat: filter sso groups based on regex

[basanthjenuhb]

Fixes #10153
Fixes #9530

Motivation

• Currently users logging in via SSO with lot of groups, exceed the 4KB Cookie limit
• This happens because we send the full set of claims as part of cookie
• Adding capability to filter sso groups matching a regex.
• This would eliminate all SSO groups which won't be used in SSO RBAC and reduce the number of groups in the authorization cookie

Modifications

• Add a property filterGroupsRegex in SSO config
• Filter groups based on the property

Verification

• Tested locally with filterGroupsRegex

Example usage:

scopes:
- groups
- email
- profile
rbac:
  enabled: true
filterGroupsRegex:
- ".*argowf.*"

[agilgur5]

Would an allowlist of groups suffice as well? Or is a regex necessary for the amount of relevant groups?

[basanthjenuhb]

Would an allowlist of groups suffice as well? Or is a regex necessary for the amount of relevant groups?

Reason for regex is to be able to add groups dynamically. And be able to filter our groups which will be relevant for argo SSO rbac. And reduce number of groups to bring the cookie size below 4kb

with allowlist we would need to update config and restart everytime we want to add a new group

[juliev0]

Good idea. So, for a given cluster there would be only one particular regex that can be matched, right? I wonder if we should make it an array of regex?

[sarabala1979]

LGTM

[sarabala1979]

@basanthjenuhb Can you add the document for this?
@terrytangyuan can we include this feature in v3.5?

[basanthjenuhb]

Good idea. So, for a given cluster there would be only one particular regex that can be matched, right? I wonder if we should make it an array of regex?

yeah
we could make it an array
but wanted to keep it simple and see how it works out for us
we can take it up as an enhancement after we see this one’s usage

[basanthjenuhb]

@basanthjenuhb Can you add the document for this? @terrytangyuan can we include this feature in v3.5?

#11778

[agilgur5]

So, for a given cluster there would be only one particular regex that can be matched, right? I wonder if we should make it an array of regex?

Julie brings up a good point here

we could make it an array
but wanted to keep it simple and see how it works out for us
we can take it up as an enhancement after we see this one’s usage

Adding a feature afterward is a bit easier said than done -- there would then be two features that need to be maintained for backward-compatibility.

If we can get ahead of a problem now, it would certainly aid maintainability

[agilgur5]

with allowlist we would need to update config

correct. that is not necessarily a bad thing though. I'm not opposed to regex but there is a security trade-off.

restart everytime we want to add a new group

there is a separate issue to improve that: #10970

[agilgur5]

So, for a given cluster there would be only one particular regex that can be matched, right? I wonder if we should make it an array of regex?

Julie brings up a good point here

Wait a minute, maybe I spoke too soon. This is a regex after all, you can do "or" conditions within a regex. Would that suffice? That would actually be simpler than having to tell users whether the array is "or" vs. "and"

Sorry I haven't been home all day, responded from my phone. Apologies if this results in rework 🙇
Will take a closer look later. Also want to check how Dex handles this case

[juliev0]

Wait a minute, maybe I spoke too soon. This is a regex after all, you can do "or" conditions within a regex. Would that suffice? That would actually be simpler than having to tell users whether the array is "or" vs. "and"

You're right. Just looked that up. It's more doable than I thought it was.

[basanthjenuhb]

Wait a minute, maybe I spoke too soon. This is a regex after all, you can do "or" conditions within a regex. Would that suffice? That would actually be simpler than having to tell users whether the array is "or" vs. "and"

yes, I had looked it up
regex does support OR. it would look like (.*patternA.*|.*patternB.*), although doable, its just not very clean compared to

filterGroupsRegex:
- ".*patternA.*"
- ".*patternB.*"

I would prefer list over single regex if the idea is to support multiple patterns.
anyways, let me know your preference. Will make the changes accordingly

[juliev0]

I would prefer list over single regex if the idea is to support multiple patterns. anyways, let me know your preference. Will make the changes accordingly

I agree if you’re open to changing it. Thanks

[basanthjenuhb]

I agree if you’re open to changing it. Thanks

already did

[agilgur5]

there's some stylistic issues in the code (it was spliced in between another block of related code), see below

[agilgur5]

I agree if you’re open to changing it. Thanks

I don't have too strong an opinion on this so long as the documentation makes clear that the list is "OR"'d together. Otherwise it may be ambiguous to users. I mentioned this in my docs review

A singular regex does not have any ambiguity; that would be the main benefit (also simpler code)

[agilgur5]

it would be great if the provider could do this logic so that the response from it is not so large, but it does not seem there is a uniform provider interface for that.

• Azure AD implements group filtering per app
• LDAP more generally has group search

There is a related Dex issue on this (dexidp/dex#1476) and generalizing it was basically closed out due to provider-specific nuances.

So I think there may be no way around filtering in the Server code unfortunately.

If a user has an IdP proxy like Dex though, they can do this group filter logic within Dex. As we get into more complex scenarios like these, we may want to consider limiting the scope of the internal implementation and forwarding users to Dex et al instead.

[agilgur5]

LGTM. Thanks for iterating on this!

[terrytangyuan]

@terrytangyuan can we include this feature in v3.5?

@sarabala1979 Sorry just saw it. Let's discuss this in the next contributors meeting on v3.5 release strategy. #11381