Interaction with google_service_account_access_token

[bbrouwer]

Until I have everything automated through CI/CD, I am trying to get my Terraform scripts to run generally as myself for auditing purposes. The GSuite admin, though, doesn't want to give me personally the power to impersonate the admin account for the scopes that this provider needs. What they are willing to do is use a service account to delegate to the admin user.

That means I need to manage the credentials for this service account, encrypt them, ... which I do have all working. But this results in decrypted credentials being stored somewhere (e.g. terraform state files from a data resource decrypted by google_kms_secret, some environment variable managed by something not terraform, ...). I'm trying to avoid the decrypted credential residing anywhere.

I stumbled upon google_service_account_access_token which seems to have very similar capabilities of impersonation. It only offers an access_token to use, while the gsuite provider only takes credentials. Would it be possible (with an enhancement), or even make sense, to give the gsuite provider this access_token instead of credentials?

I'm thinking of some config looking like this:

provider "google" {}

data "google_service_account_access_token" "gsuite" {
  target_service_account = "gsuite-service-account@myproject.iam.gserviceaccount.com"
  scopes = [
    "not exactly sure what scopes I need here",
  ]
}

provider "gsuite" {
  access_token = "${data.google_service_account_access_token.gsuite.access_token}"
  impersonated_user_email = "admin@gfs.com"

  oauth_scopes = [
    "https://www.googleapis.com/auth/admin.directory.group",
    "https://www.googleapis.com/auth/admin.directory.group.member",
  ]
}

Basically, this is doing a double impersonation. First my personal account impersonates the service account, and then the gsuite provider impersonates the admin user account.

This way no service account credential is ever referenced in state. There is an access_token that might end up in state somewhere, but it is short lived, so it isn't as bad.

Or am I just going about this all the wrong way and there is a far simpler approach?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[flapp]

I'm actually running into a very similar situation, and being able to use the access token would be a very nice addition!

[DeviaVir]

Took a shot at this with this branch, but unfortunately I got stuck with the second impersonate using only an access token: https://github.com/DeviaVir/terraform-provider-gsuite/pull/new/access_token perhaps someone else would like to take that branch and make it work.

[claywd]

perhaps someone else would like to take that branch and make it work.

Working on it. ;-)

[claywd]

@DeviaVir you in the golang slack channel? if so can you dm me @bit_wrangler? Wanna chat this stuff up a little to better understand why we are impersonating user emails at all.

[DeviaVir]

@DeviaVir you in the golang slack channel? if so can you dm me @bit_wrangler? Wanna chat this stuff up a little to better understand why we are impersonating user emails at all.

@Claywd so sorry for the late reply, I'm not in the golang slack channel but I can be. I'm also on freenode/DeviaVir

[ocervell]

@Claywd @DeviaVir hey folks, would you have any update on this ? I need this in a Cloud Build pipeline to impersonate anoter service account w/ Domain-wide delegation that will impersonate my admin user ... Thanks !