Fix support for GSuite logins

[klizhentas]

This commit fixes support for GSuite logins
by using service accounts for access purposes.

The resulting connector now looks like:

kind: oidc
version: v2
metadata:
  name: gsuite
spec:
  redirect_url: https://example.com/v1/webapi/oidc/callback
  client_id: exampleclientid.apps.googleusercontent.com
  client_secret: exampleclientsecret
  issuer_url: https://accounts.google.com
  # Notice that scope here is not requiested from OIDC exchange anymore, this scope
  #
  # https://www.googleapis.com/auth/admin.directory.group.readonly
  #
  # is now implicitly requested by the client
  #
  scope: ['openid', 'email']
  # The setup below is involved and requires careful following of the guides:
  #
  # https://developers.google.com/admin-sdk/directory/v1/guides/delegation
  # https://developers.google.com/identity/protocols/OAuth2ServiceAccount#delegatingauthority
  #
  # The service account scope has to be set to
  #
  # https://www.googleapis.com/auth/admin.directory.group.readonly
  google_service_account_file: "/home/sasha/google/gsuite-creds.json"
  google_admin_email: "sasha@gravitational.com"
  claims_to_roles:
    - {claim: "groups", value: "dev@gravitational.com", roles: ["clusteradmin"]}

[klizhentas]

Folks, please review once you get a chance.

@benarent some open questions:

• I have used google_service_account_file approach instead of adding JSON to yaml. This has it's advantages and disadvantages.

Cons:

• The file has to be distributed on every auth server that supports this in HA mode
• OIDC connector is not self-sufficient and portable

Pros:

• Mounted and external service accounts can be used with this approach, rotated and short term ones in GKE for example
• Less potential for mistakes

Please review with the product team, and either way, we have to make a call.

There is additional changes - the service account approach will only work if it impersonates the request from some real user, in my example it's me. That's why I had to add this as an additional field.

The scope no longer requests the admin.groups.readonly, because it will break the login screen, and instead reuqests it via serviceaccount.

Domain wide delegation should be enabled and it takes a couple of minutes to kick in sometimes.

Needless to say this needs guide update as well.

[webvictim]

Fixes #3029

[fspmarshall]

In general, it seems better to not have reliance on local state be the default behavior. Perhaps the google_service_account_file field could be peeked for a file:// scheme prefix, and otherwise interpreted as in-line json?

[benarent]

Extra note: When managing service access via Google Admin, these are the two permissions needed.

https://www.googleapis.com/auth/admin.directory.group.member.readonly, https://www.googleapis.com/auth/admin.directory.group.readonly

[benarent]

I noticed that this change added

google_admin_email: ""
google_service_account_file: ""

into my already exsiting OIDC connectors, I copied over https://gravitational.com/teleport/docs/oidc/#oidc-connector-configuration , and this was the result.

Is it possible to not add it into the connector? Or is it required for validation? I don't want to create extra confusion for 0Auth and KeyClock users.

[klizhentas]

@benarent I think I can fix that

[klizhentas]

@benarent fixed

[benarent]

We reviewed the config options this morning and we are recommending to use Forrests suggestion of using file:// URI schema, similar to the current process for Gravity Image Manifest Format. https://gravitational.com/gravity/docs/pack/

[klizhentas]

@benarent @russjones @fspmarshall please re-review. I've updated the docs in the commit as well with the changes.

Have adopted the file:/// scheme and changed the name of the google_service_account_file to google_service_account_uri to match our conventions.

Inline json is not supported as well as any other schemes for now.

[benarent]

Just updated my cluster and successfully tested the updated G Suite service key URI.

[klizhentas]

retest this please