googleworkspace_group_settings Request had insufficient authentication scopes.

[halradaideh]

Terraform Version

1.0.0

Affected Resource(s)

• googleworkspace_group_settings

Terraform Configuration Files

provider "googleworkspace" {
  credentials = "X.json"
  impersonated_user_email = "X"
  oauth_scopes = [
    "https://www.googleapis.com/auth/admin.directory.group",
    "https://www.googleapis.com/auth/admin.directory.user",
  ]
  customer_id = "X"
}


resource "googleworkspace_group" "X" {
  email         = "X"
  description   = "Managed by TF | X"
}

resource "googleworkspace_group_settings" "X" {
  email = googleworkspace_group.X.email

  allow_external_members = false

  who_can_join            = "INVITED_CAN_JOIN"
  who_can_view_membership = "ALL_MANAGERS_CAN_VIEW"
  who_can_post_message    = "ALL_MEMBERS_CAN_POST"
}

Expected Behavior

to run

Actual Behavior

Request had insufficient authentication scopes

Steps to Reproduce

1. terraform apply

Important Factoids

BTW I can create groups and add members to groups using the service account

[megan07]

Hi @halradaideh ! Would you mind trying it with https://www.googleapis.com/auth/apps.groups.settings added to the list of scopes? The group settings is a separate API and has a separate scope. Let me know if that still doesn't work and I'll take a deeper look. Thanks!

[halradaideh]

yup worked, please modify documentation :D

[sajidk1]

@halradaideh @megan07

Even with the additional scope I'm still getting:

googleworkspace_group_settings.settings: Creating...
╷
│ Error: googleapi: Error 403: Request had insufficient authentication scopes.
│ More details:
│ Reason: insufficientPermissions, Message: Insufficient Permission
│ 
│ 
│   with googleworkspace_group_settings.settings,
│   on main.tf line 11, in resource "googleworkspace_group_settings" "settings":
│   11: resource "googleworkspace_group_settings" "settings" {
│ 

My config:

provider "googleworkspace" {
  customer_id             = "X"
  oauth_scopes = [
    "https://www.googleapis.com/auth/admin.directory.group",
    "https://www.googleapis.com/auth/admin.directory.user",
    "https://www.googleapis.com/auth/apps.groups.settings"
  ]
}

resource "googleworkspace_group_settings" "settings" {
  email = "[email protected]"

  allow_external_members = true
}

I've authenticated with my superadmin account like so: gcloud auth login --update-adc

Service account

I've omitted the use of a GCP service account for now, but if add one to impersonated_user_email e.g. [email protected], and give it a suitable admin role e.g. Groups Editor, could that work if said operation was running inside GCP (CloudBuild)?

#127 seems to suggest this isn't feasible right now.

[halradaideh]

@sajid-khan-js did you added it to workspace deligation client scopes?

[sajidk1]

As in this? https://developers.google.com/admin-sdk/directory/v1/guides/delegation#delegate_domain-wide_authority_to_your_service_account

This talks about how that shouldn't be required anymore i.e. you can assign a service account admin roles directly.

Regardless, why doesn't it work with my super admin account's application default credentials?

If not provided, the application default credentials will be used.

From: https://registry.terraform.io/providers/hashicorp/googleworkspace/latest/docs

[sajidk1]

Ended up actually reading the docs 😆 and noticed this: https://registry.terraform.io/providers/hashicorp/googleworkspace/latest/docs#authentication

I have managed to get it working by using the domain wide delegation method.

@megan07 is there any planned support for https://workspaceupdates.googleblog.com/2020/08/use-service-accounts-google-groups-without-domain-wide-delegation.html in the provider?

Thanks

[sajidk1]

No domain wide delegation required :)

Just to update the thread, I did get this working with a service account without having to setup domain wide delegation (as per the release notes here).

Essentially: admin.google.com > Admin roles > Groups Editor > Assign service accounts

This simplifies the provider config, as you don't need to worry about scopes or even impersonating a user since the service account has direct access to the Workspace API.

provider "googleworkspace" {
  credentials  = "my_sa.json"
  customer_id  = "X"
}

resource "googleworkspace_group_settings" "settings" {
  email = "[email protected]"

  allow_external_members = true
  ....
}

Someone had a similar outcome with the old provider too: DeviaVir/terraform-provider-gsuite#156 (comment)

Application default credentials

The last thing I want to understand more is whether I can use this provider without a static service account key. We discourage the use of them (as do Google in whitepapers and docs), and in fact we block the creation of service account keys for the majority of our GCP projects using an GCP org policy

So, ideally, I want to be able to interact with the provider via application default credentials. This allows an authenticated human running terraform locally to user this provider, and will allow a GCP resource which has a service account assigned e.g., Cloud Build to run this provider without a static service account key.

This comment gives a working method for a human user and I got it working with this provider, but it requires an interactive login, any ideas on how to use this with short-lived credentials inside a GCP environment e.g., Cloud Build?

#127 Looks promising

Thanks

[megan07]

Hi all! I have a PR open to fix the initial issue noted above (documentation for scopes). Feel free to open a new issue (or follow #127) for further requests. Thanks!

[antonhihealth]

as of Dec 2023, I can confirm what @sajidk1 said still works.

• remove scopes and impersonated user from google provider config
• assign service account to Groups Editor in G Admin
• save credentials json file of the said service account to the env var GOOGLEWORKSPACE_CREDENTIALS
• log into G CLI via gcloud auth login
• magic