feat: allow Workload Identity Federation for Google connector

[midu-git]

Overview

• A new Google connector option have been introduced, i.e.,
  serviceAccountToImpersonate. If this field is non-empty, it is
  assumed that Workload Identity Federation shall be used, and the
  linked service account needs to be configured for domain-wide
  delegation. Moreover, the service account used for Workload Identity
  Federation must include Service Account Token Creator for this
  service account.
• Print some warnings if the configuration is not consistent or erroneous.
• Fix fetching groups to rely on groups as scope. In the case groups
  is specified as a scope, the oauth authentication call will fail as
  Google doesn't support it. Moreover, as fetching groups requires the
  group directory service, it is enough to assume the existence of this
  service as a prerequisite for the fetch. If 'groups' is specified as a
  scope, a warning is printed, instead of erroring out, for backwards
  compatibility reasons.
• When specifying groups in the configuration, but no group directory
  service will be created, a warning is printed that the groups
  configuration will be ignored.

What this PR does / why we need it

The code doesn't support Workload Identity Federation so far. Workload Identity Federation enables interaction with Google services without requiring to provide any sensitive credential data on the caller side, c.f. here.

Special notes for your reviewer

Does this PR introduce a user-facing change?

* A new Google connector option have been introduced, i.e.,
  "serviceAccountToImpersonate". If this field is non-empty, it is
  assumed that Workload Identity Federation shall be used, and the
  linked service account needs to be configured for domain-wide
  delegation. Moreover, the service account used for Workload Identity
  Federation must include "Service Account Token Creator" for this
  service account.
* Print some warnings if the configuration is not consistent or erroneous.
* Fix fetching groups to rely on "groups" as scope. In the case "groups"
  is specified as a scope, the oauth authentication call will fail as
  Google doesn't support it. Moreover, as fetching groups requires the
  group directory service, it is enough to assume the existence of this
  service as a prerequisite for the fetch. If "groups" is specified as a
  scope, a warning is printed, instead of erroring out, for backwards
  compatibility reasons.
* When specifying "groups" in the configuration, but no group directory
  service will be created, a warning is printed that the groups
  configuration will be ignored.

[midu-git]

@nabokihms Can I somehow support the process of reviewing this PR?

[midu-git]

@nabokihms I know that you guys are very busy, but this feature is very important for us. Therefore, can I support the progress here somehow?

[jacek-jablonski]

I've manually tested this PR and it works fine. It also fixes: #3348

It would be great if it was merged.

[Pionerd]

Please consider using the Cloud Identity API for the groups. This great project by @jkroepke has a PR open for it and it works like a charm. It's no longer necessary to use a service account and/or domain admin email to impersonate.

jkroepke/openvpn-auth-oauth2#196

[jkroepke]

Please consider using the Cloud Identity API for the groups.

You can use the token of the users access token with scope https://www.googleapis.com/auth/cloud-identity.groups.readonly to fetch the groups, without an additional identity.

Some credits: https://github.com/grafana/grafana/blob/110028706a160af8c66672d06554f616d660d82c/pkg/login/social/connectors/google_oauth.go#L242-L298

API docs: https://cloud.google.com/identity/docs/reference/rest/v1beta1/groups.memberships/searchDirectGroups

[smileisak]

Any news on this ?

[midu-git]

Due to time constraints, I've not been working on this PR unfortunately. While I agree that using groups API without user impersonation is definitely the way to go, this PR has a different scope. It is about Workload Identity Federation, i.e., using a Service Account without the necessity to store credentials. And this feature was definitely worth being included to dex.
However, I've created a new PR that uses Cloud Identity API to fetch groups, and uses Application Default Credentials, thus supporting Workload Identity Federation as well.
I guess, this one becomes obsolete, once the other is merged.