Google SSO nested groups

[klizhentas]

Description

Google nested group are not expanded when fetching groups using our oauth code
TLDR: when user is a member of a group that is a subgroup of another gmail, it’s not reflected in the groups arriving in SSO.

[corkrean]

This is confirmed. Groups do not have upward expansion. i.e Members of the child group will not have parent group membership passed to Teleport.

[corkrean]

Reproduction steps:

1. Navigate to the google workspace admin Console. Two-week trials are available, but there is no free tier.
2. Create a group. We will call this group parent-group
3. Create another group. We will call this group child-group
4. From the groups' list, add child-group as a member of parent-group
5. Create a user, we will call them test-user
6. Add test-user as a member of child-group
7. Create an OIDC auth connector in Teleport that will map the google group parent-group to the Teleport role google-tester

kind: oidc
metadata:
  name: google
spec:
  claims_to_roles:
  - claim: groups
    roles:
    - google-tester
    value: <parent-group@example.com>
...

8. Observe the SSO login audit log that the SSO login failed because only the child-group and not parent-group was passed in the OIDC attributes.

In the above scenario, test-user is considered a direct member of child-group and an indirect member of parent-group

Important note: Google makes it explicit that

"Members of child groups are not direct members of parent groups. Because child group members don't belong to parent groups, they, don’t appear as members of the parent group." Link

[xacrimon]

Attempted to solve this a little while ago and ran into some issues.

• Fetching nested groups memberships requires a newer version of the google/api/cloudidentity package to use groups.SearchTransitiveMemberships.
• This pulls in google/api package v0.58 (up from v0.27) since all the Google packages are bundled together.
• This updates the google.golang.org/grpc package.

Then this import chain error happens:

github.com/gravitational/teleport/lib/backend/etcdbk imports
	go.etcd.io/etcd/clientv3 tested by
	go.etcd.io/etcd/clientv3.test imports
	go.etcd.io/etcd/integration imports
	go.etcd.io/etcd/proxy/grpcproxy imports
	google.golang.org/grpc/naming: module google.golang.org/grpc@latest found (v1.41.0), but does not contain package google.golang.org/grpc/naming

etcd is stuck on an old version of grpc/naming (since early 2020) and due to how Google bundles their packages we cannot easily just upgrade cloudidentity without upgrading grpc. An issue for this previously existed in the etcd repository but since looks to have been deleted. I think we're also pulling coreos/etcd instead of etcd.io/etcd which looks older.

A big dependency update pass is probably in order since this isn't the only wierd dep-issue.

[dmsergeevN26]

This is relevant to our interests

[espadolini]

A working (draft) implementation is available in #9697; the new functionality relies on the groups.memberships.searchTransitiveGroups call from the Google Cloud Identity API as opposed to the groups.list call from the Google Workspace Admin SDK Directory API.

Both rely on the same exact setup: an OAuth 2.0 client id and a service account with domain-wide delegation for a read-only scope (https://www.googleapis.com/auth/cloud-identity.groups.readonly or https://www.googleapis.com/auth/admin.directory.group.readonly, respectively). The Cloud Identity APIs don't require impersonating a workspace admin, but searchTransitiveGroups requires impersonating a user that has view permissions on the whole group membership tree of the user being checked - if all the users that are supposed to log in can view all their transitive groups, we can just impersonate the user that's attempting to log in. Impersonating an admin is still a possibility.

The Cloud Identity API has some extra licensing requirements: the member being checked must be licensed for Google Workspace Enterprise or for Cloud Identity Premium (at least in theory - maybe it's an effect of our current free trial but even a brand new account with no licenses seems to be successful in calling the API).

The draft implementation adds an extra boolean option to the OIDC connector resource, to select between the Directory API that we're already using - which only returns direct group memberships and requires specifying a workspace admin user to impersonate - and the Cloud Identity API - which always returns transitive group memberships, depending on the configuration can either impersonate the user that's logging in or a workspace admin, and might require extra licensing. This will require more documentation to explain the difference between the two options but has perfect backwards compatibility with existing configurations; alternatively we could only support the new API starting from version 9 and mention the new requirements in the upgrade guide.

[russjones]

The Cloud Identity API has some extra licensing requirements: the member being checked must be licensed for Google Workspace Enterprise or for Cloud Identity Premium (at least in theory - maybe it's an effect of our current free trial but even a brand new account with no licenses seems to be successful in calling the API).

Yeah, but not sure if we want to rely on that, might get swapped out on us at any moment.