Google Groups

This feature is part of the Enterprise plan. If it is not enabled for your organization, please contact StrongDM at the StrongDM Help Center.

Overview

The Google Groups resource type lets StrongDM grant users time-bound membership in Google Groups. You bind each group to Google Cloud IAM roles ahead of time. When a user is granted a privilege level on the resource, StrongDM adds the user's Google identity to the corresponding group. When the grant expires or is revoked, StrongDM removes them. Users authenticate to Google Cloud as they normally do. StrongDM is not in the authentication path and never edits IAM policies.

Google Groups resources support Just-in-Time (JIT) access. Admins can grant temporary access directly to a user, or users can request a privilege level through an access workflow and be approved or denied by configured approvers.

How It Works

Privilege levels on a Google Groups resource are Google Group email addresses, such as gcp-prod-viewers@example.com. Each privilege level maps to one group. A user who holds the privilege level is a member of the group, and the group's IAM role bindings decide what that membership grants in Google Cloud.

When a user is granted a privilege level, a StrongDM node adds the user's Google identity to the group. StrongDM resolves that identity from the user's Identity Alias in the Identity Set configured on the resource. About every 10 minutes, StrongDM verifies the user is still in the group and re-adds them if they were removed outside StrongDM, until the grant expires or is revoked. A grant that failed to provision is retried about every minute. At that point StrongDM removes the user from the group, even if they were a member before the grant.

Google applies group membership changes to IAM asynchronously. According to Google's access change propagation documentation, a membership change typically takes effect within several minutes but can take longer, and removals propagate more slowly than additions. StrongDM records the grant and the revocation immediately, but the user's effective access in Google Cloud follows Google's timeline.

Limitations

No end-user connection is made through StrongDM. Users do not launch the resource from the StrongDM Desktop application or CLI. They authenticate to Google Cloud as usual, with the access their group memberships provide.
Google Groups privilege levels cannot be used in policies.
Google Groups resources cannot be added to access rules in roles or to dynamic access rules. They can be added only to the static access rule of an access workflow, and a static rule can hold only one Google Groups resource.
Only static groups are supported. A dynamic group, whose membership is defined by a query, cannot be edited through the API. A grant on a dynamic group fails at the first grant with an error from the node.
Do not use groups whose membership is mastered by an external directory sync, such as a SCIM sync from Microsoft Entra ID or Okta into Google. The sync reverts StrongDM's changes and StrongDM re-applies them, so membership flaps.
Do not use groups that also drive Google Workspace provisioning in StrongDM. A temporary grant to such a group would also change the user's StrongDM role membership.
The health check cannot confirm that the node is allowed to manage group membership. Google's API offers no read-only way to check that permission, so the first grant is the first real test. See Verify the node is reachable.

Prerequisites

In StrongDM, you must have the Admin permission level, and your organization must have the Enterprise plan.
To assign an admin role to a service account (option A in Set Up Google, and discovery), you must be a super administrator in the Google Admin console for your Google Workspace or Cloud Identity account. Making the service account a Manager of a group (option B) needs only the right to edit that group.
You must be able to create a service account and enable APIs in a Google Cloud project.
Your users must exist in your Google Workspace or Cloud Identity directory. StrongDM maps each StrongDM user to a Google identity by email address.
The groups that StrongDM manages should be static groups created for this purpose and already bound to the IAM roles you want to grant.

Set Up Google

The StrongDM node that serves the resource authenticates to Google as a service account, using Google's Application Default Credentials (ADC). StrongDM stores no Google credentials. Access to the groups is granted in the Google Admin console, not in Google Cloud IAM. No Google Cloud IAM roles are needed.

The following table lists everything the node's service account needs. The steps that follow set each one up.

Requirement

Where it is set

Needed for

Cloud Identity API (cloudidentity.googleapis.com) enabled

Service account's Google Cloud project

Grants, revokes, and health checks

Admin SDK API (admin.googleapis.com) enabled

Service account's Google Cloud project

Discovery only

Credentials available to the node through ADC

Node

Everything

Groups Admin role, or membership with the Manager role in each group StrongDM manages

Google Admin console

Grants and revokes

Groups Reader role (or Groups Admin)

Google Admin console

Discovery only

The node requests the OAuth scope https://www.googleapis.com/auth/cloud-identity.groups for grants and revokes, and https://www.googleapis.com/auth/admin.directory.group.readonly for discovery. You do not configure these scopes, except on a Compute Engine VM as described in step 2.

Step 1: Create a service account and enable the APIs

In the Google Cloud console, select the project that will own the node's service account, and then create a service account. Record its email address, such as strongdm-jit@<PROJECT_ID>.iam.gserviceaccount.com. Do not grant it any IAM roles for this feature.
In the same project, go to APIs & Services > Library and enable the Cloud Identity API.
If you intend to enable discovery on the resource, also enable the Admin SDK API.

Step 2: Give the node the service account's credentials

The node finds its credentials through ADC. Use the option that matches where the node runs.

Attach the service account to the VM that runs the node, and set the VM's access scope to Allow full access to all Cloud APIs (the cloud-platform scope). Access scopes limit which APIs the VM can call with OAuth, and the default scopes do not include the Cloud Identity API. Both settings are on the VM's edit page in the Google Cloud console under Identity and API access. The VM must be stopped to change them.

No files or environment variables are needed on the node.

Use Workload Identity Federation for GKE and link the node's Kubernetes service account to the Google service account from step 1. Annotate the Kubernetes service account with iam.gke.io/gcp-service-account=<SERVICE_ACCOUNT_EMAIL> and grant the Kubernetes service account the roles/iam.workloadIdentityUser role on the Google service account.

The link to a Google service account is required. The Google Admin console assigns roles and group memberships to a service account email address, and a Kubernetes service account used directly as an IAM principal has no such address.

In the Google Cloud console, open the service account, go to Keys, and create a JSON key. Download it.
Copy the key file to the node and restrict its permissions so only the StrongDM service can read it.
Set the following environment variable for the StrongDM service on the node. This is often done in /etc/sysconfig/sdm-proxy (or sdm-worker for a proxy worker).
```
GOOGLE_APPLICATION_CREDENTIALS="/etc/strongdm/google-service-account.json"
```
Restart the StrongDM service on the node.

Step 3: Grant the service account access to the groups

Choose one of the following. Both are done in the Google Admin console, and both were verified against a live Google Workspace account.

Option A: Groups Admin role

The service account can manage every group in your account. This is the simpler option, and it also satisfies discovery.

In the Google Admin console, go to Account > Admin roles.
Point to the Groups Admin role, and then click Assign admin.
Click Assign service accounts, enter the service account's email address, and click Add.
Click Assign role.

Google states that role changes can take up to 24 hours but typically apply within minutes. In testing, the assignment took about 15 minutes.

Option B: Manager of each group

The service account can manage only the groups you add it to. This is the least-privilege option. It is not sufficient for discovery.

In the Google Admin console, go to Directory > Groups, and open a group that StrongDM will manage.
Click Members > Add members, enter the service account's email address, and click Add to group. The account is added with the Member role.
In the members list, under Role for the service account, click the down arrow, select Manager, and then click Save.
Repeat for every group that will be a privilege level on the resource.

If you enable discovery

Discovery lists every group in the Workspace domain through a read-only Admin SDK call. That call requires an admin role. If you chose option A, nothing more is needed. If you chose option B, also assign the service account the Groups Reader role using the steps from option A.

Set Up Google Groups in StrongDM

Verify the node is reachable

After you add the resource, its Diagnostics tab in the Admin UI lists the nodes that can reach Google. Because the node holds its own credentials, the health check should pass as soon as the resource exists. If you use a proxy cluster to reach Google, assign the cluster to the resource, and the health check passes through it.

The health check confirms that the node's credentials resolve, that the Cloud Identity API is enabled for the service account's project, and that the resource has a Workspace domain. It cannot confirm that the service account may manage group membership, because Google's API gives no read-only way to check. A resource can therefore show healthy and still fail its first grant if step 3 was skipped. When that happens, the failure and its cause appear in the Activity logs. See Troubleshooting.

To pin the resource to specific nodes, tag them with sdm admin nodes update <NODE_ID> --tags sdm__google_domain=<WORKSPACE_DOMAIN> (note the two underscores between sdm and google). StrongDM then uses only the tagged nodes for this domain, regardless of the health status of any other node.

Set up Identity Aliases

StrongDM adds a user to a group by the user's Google email address, which it reads from the user's Identity Alias in the resource's Identity Set.

If your users' StrongDM email addresses match their Google email addresses exactly, select the default email Identity Set when you add the resource. No Identity Aliases need to be created.

If the addresses differ, create an Identity Set and an Identity Alias for each user:

In the Admin UI, go to Principals > Identity Sets > Add set. See Identity Aliases for details.
Go to Principals > Users, open a user, and select the Identity Aliases tab.
Click Add Alias, select the Identity Set, and enter the user's exact Google email address, such as alice.glick@example.com.

Add the resource

Add the resource with the Admin UI, CLI, Terraform provider, or SDKs.

Log in to the Admin UI and go to Resources > Managed Resources.
Click Add Resource.
For Resource Type, select Google Groups.
Set the resource properties. Choose one of the following ways to define privilege levels:
- Leave Discovery Enabled off and list the group email addresses in Privilege Levels.
- Turn Discovery Enabled on. StrongDM lists the groups in your Workspace domain and offers them as privilege levels wherever a privilege is chosen. Use Group Emails to narrow the list, for example gcp-*@example.com. Discovered groups also appear on the resource's Discovery tab.
Click Create.
Click the resource name to view its status and diagnostics. The Health icon turns green when the health check passes.

Run sdm admin clouds add googleGroups --help to view the available options, which look like the following.

NAME:
   sdm admin clouds add googleGroups - create Google Groups cloud

USAGE:
   sdm admin clouds add googleGroups [command options] <name>

OPTIONS:
   --discovery-enabled        Enable discovery for the Google Workspace account.
   --domain value             the primary domain of the Google Workspace account that owns the groups (required)
   --egress-filter value      apply filter to select egress nodes e.g. 'field:name tag:key=value ...'
   --group-emails value       Enter one or more group email addresses to match. Use commas to separate multiple addresses. Supports wildcards (e.g., admin-*@example.com). Only groups with matching email addresses will be discovered.
   --identity-set-id value    (required)
   --identity-set-name value  set the identity set by name
   --privilege-levels value   comma separated list of Google Group email addresses (conditional)
   --proxy-cluster-id value   proxy cluster id
   --tags value               tags e.g. 'key=value,...'
   --template, -t             display a JSON template
   --timeout value            set time limit for command

Run sdm admin clouds add googleGroups <RESOURCE_NAME> with the required properties. For example, without discovery:

sdm admin clouds add googleGroups "google-groups-prod"
  --domain "example.com"
  --identity-set-name "email"
  --privilege-levels "gcp-prod-viewers@example.com,gcp-prod-editors@example.com"
  --tags "env=prod"

Or with discovery:

sdm admin clouds add googleGroups "google-groups-prod"
  --domain "example.com"
  --identity-set-name "email"
  --discovery-enabled \
  --group-emails "gcp-*@example.com"
  --tags "env=prod"

Confirm the resource exists:
```
sdm admin clouds list
```

The following example uses the Terraform provider.

terraform {
  required_providers {
    sdm = {
      source  = "strongdm/sdm"
      version = ">= 18.0.0"
    }
  }
}

provider "sdm" {
  # Add API access key and secret key from the Admin UI
  api_access_key = "njjSn...5hM"
  api_secret_key = "ziG...="
}

resource "sdm_resource" "google_groups_prod" {
  google_groups {
    # Required
    name            = "google-groups-prod"
    domain          = "example.com"                        # --domain
    identity_set_id = "ig-a1b2c3d4"                        # --identity-set-id

    # Privilege levels, when discovery is off
    privilege_levels = "gcp-prod-viewers@example.com,gcp-prod-editors@example.com"

    # Discovery, as an alternative to privilege_levels
    # discovery_enabled = true
    # group_emails      = "gcp-*@example.com"

    # Optional networking
    egress_filter    = "tag:env=prod"                      # --egress-filter
    proxy_cluster_id = "plc_abcdef0123456789"              # --proxy-cluster-id

    tags = {
      env = "prod"
    }
  }
}

You can also manage the resource with the Go, Java, Python, and Ruby SDKs.

Java

Python

Ruby

Resource properties

The Google Groups resource type has the following properties.

Property

Requirement

Description

Display Name

Required

A meaningful name for this resource; displays throughout StrongDM; no special characters like quotes (") or angle brackets (< or >)

Resource Type

Required

Google Groups

Proxy Cluster

Required

Defaults to “None (use gateways)”; if using proxy clusters, select the cluster whose nodes hold the Google credentials

Google Workspace Domain

Required

Primary domain of the Google Workspace or Cloud Identity account that owns the groups, such as example.com

Identity Set

Required

Identity Set whose Identity Aliases hold each user's Google email address; the default email set works when StrongDM and Google emails match

Discovery Enabled

Optional

When enabled, StrongDM lists the groups in the domain and offers them as privilege levels; discovered groups appear on the Discovery tab

Group Emails

Optional

Comma-separated filters that limit which discovered groups are offered as privilege levels; supports * wildcards and matches case-insensitively, such as gcp-*@example.com; appears when discovery is enabled

Privilege Levels

Required

Comma-separated email addresses of the groups to manage, such as gcp-prod-viewers@example.com,gcp-prod-editors@example.com; appears when discovery is not enabled

Resource Tags

Optional

Enter tags consisting of key-value pairs <KEY>=<VALUE> (for example, env=dev)

Manage Google Group Membership With StrongDM

There are two ways to grant a privilege level on a Google Groups resource:

Temporary access. In the Admin UI, go to Principals > Users, select the user, open the Entitlements tab, and click Grant temporary access. Select the resource, and then select one or more groups in the Select Google groups as privileges field.
Access workflow. Create an access workflow whose static access rule includes the Google Groups resource. Under Google Groups privileges, select the groups users may request. Users then request a group from the catalog in the Admin UI, Desktop app, or CLI, and approvers approve or deny the request.

Groups are shown by email address in every picker. After a grant is provisioned, the Admin UI notes that access may take a few minutes to become active in Google Cloud. See How It Works.

Roles and dynamic access rules are not a grant path. StrongDM changes group membership only when a temporary access grant or an approved access request creates a grant with an end time. The Admin UI does not allow a Google Groups resource in a role's access rule. The API and Terraform provider accept one. The resource then appears in the user's entitlements and in sdm status, but StrongDM does not change any group membership for it.

Verify group membership additions or revocations

After a grant, open the group in the Google Admin console under Directory > Groups and confirm the user appears as a member. After the grant expires or is revoked, confirm the user is gone.

Revocation removes the user even if they were added to the group outside StrongDM before the grant. For example, if Alice was added to gcp-prod-viewers@example.com directly in the Admin console and later granted the matching privilege level in StrongDM, she is removed from the group when her StrongDM grant ends.

Request access from the CLI

To request a Google Groups privilege level from the CLI, add the --googleGroup option with the group's email address. Repeat the option to request more than one group.

sdm access to <RESOURCE_ID> --duration 10m --reason "example reason for request" --googleGroup gcp-prod-viewers@example.com

Admins can grant temporary access from the CLI the same way:

sdm admin users grant-temporary --duration 1h --googleGroup gcp-prod-viewers@example.com <RESOURCE_NAME> <USER_EMAIL>

Logs

When a user is added to a group for a privilege level, the Activity logs record User external grant provisioned. When the user is removed at expiry or revocation, the logs record User external grant revoked. If the node could not make the change, the logs record User external grant provision failed or User external grant revocation failed with the error from the node.

StrongDM does not log the user's actions in Google Cloud because it does not proxy the connection.

Troubleshooting

The resource is healthy but grants fail. This is expected when the service account has not been given access to the groups. The health check cannot detect that condition. Check the Activity logs for User external grant provision failed and read the error.
The error says the group may not exist, or the service account may lack access to it. Google returns the same error for a misspelled group email and for a group the service account cannot see. Check the group email in the privilege level, and confirm that the service account holds the Groups Admin role or is a Manager of that group.
The error says the service account cannot manage members of the group and may only have read access. Google returns this error in two cases: the service account can see the group but cannot change its membership, or the user's email address is not a Google account. First check the user's Identity Alias. It must be an account in your Google Workspace or Cloud Identity directory; a StrongDM email address at a domain Google does not know fails this way. If the alias is correct, make the service account a Manager of the group, or assign it the Groups Admin role. Groups Reader alone is not enough.
The health check fails and the error names the Cloud Identity API. Enable cloudidentity.googleapis.com on the Google Cloud project that owns the service account.
The health check fails and the error mentions Application Default Credentials. The node found no credentials. Check that GOOGLE_APPLICATION_CREDENTIALS points to a readable key file, or that the VM or pod has a service account attached, and restart the StrongDM service.
Discovery fails and the error says the service account cannot list the groups of the domain. Assign the service account the Groups Reader or Groups Admin role. Being a Manager of individual groups does not allow listing the domain.
Discovery fails and the error names the Admin SDK API. Enable admin.googleapis.com on the service account's project. It is separate from the Cloud Identity API.
Grants succeed but the user does not gain access in Google Cloud right away. Google applies group membership changes to IAM asynchronously. Wait several minutes. If the group is a dynamic group, or its membership is managed by an external sync, use a static group created for StrongDM instead.
Grants converge intermittently. Tag the nodes you know are healthy with sdm__google_domain=<WORKSPACE_DOMAIN> so that only those nodes are used for the domain.
After switching to a different service account, the node still fails. The node caches its Google client for up to 20 minutes. After changing the key file or the attached service account, restart the StrongDM service on the node, or wait for the cache to expire. Changes made in the Google Admin console, and APIs enabled in the Google Cloud console, need no restart. They apply on the next attempt once Google has propagated them.

Last updated 21 days ago

Was this helpful?