Set up a Google Cloud Platform with Google Workspace connector

Capabilities

Resource	Sync	Provision
Accounts
Groups
Folders
Roles
Projects
Organizations
Workforce Identity pools*
Workforce Identity pool providers*
Secrets - API keys
Secrets - Service account keys
Secrets - Secret Manager secrets
Buckets
IAM Role Assignments**

*Workforce Identity Federation support is optional and must be configured when you set up the connector.

What Workforce Identity provisioning covers. Entitlements on a Workforce Identity pool are the administrative roles bound on the pool itself — who may manage the pool and its providers. Reading them requires iam.workforcePools.getIamPolicy, and granting or revoking them additionally requires iam.workforcePools.setIamPolicy. The three roles GCP predefines for this (roles/iam.workforcePoolAdmin, roles/iam.workforcePoolEditor, roles/iam.workforcePoolViewer) always appear as entitlements, so a newly created pool can be administered from C1 straight away, and any other role the pool binds appears alongside them. C1 shows who holds each of those roles, including principals GCP grants only while an IAM condition holds. Granting a pool role writes an unconditional binding. If the principal also holds that role under a condition — either by itself or alongside an unconditional binding — C1 refuses the revoke before making any policy change. Remove the conditional binding in GCP, then retry the revoke in C1 to remove any remaining unconditional binding.Separately, federated identities can be granted and revoked IAM roles on organizations, folders, projects, buckets, and secrets. The connector writes the appropriate GCP principal for each shape — principal://…/subject/… for a single user, and principalSet://…/group/…, principalSet://…/attribute.NAME/… or principalSet://…/* for the set-based bindings. Across these resource roles and the pool administrative roles above, when a Shared identity source matches the same identity through more than one workforce pool, C1 refuses a revoke that would remove only one binding and leave the matched identity’s access in place through another pool. Remove the duplicate binding in GCP, sync the connector, and retry the revoke.Granting access to a federated group must be done in GCP. GCP identifies such a group by the value its provider asserts in the google.groups claim, which varies by identity provider and cannot be derived from the group itself, so the connector refuses the grant rather than writing a binding that would match no one. Once the principalSet://…/group/… binding exists in GCP, the connector syncs it and can revoke it. With a Shared identity source configured, C1 matches the asserted group to the group from that source and shows the binding’s inherited IAM access for its members in Inventory and access reviews. Configure the Shared identity source when you enable Workforce Identity Federation so group-derived access includes those members. Without it, C1 still shows access held by the federated group binding itself.Bindings that address an open-ended set of identities — principalSet://…/attribute.NAME/… and principalSet://…/* — are synced as read-only. C1 shows them against every identity they match, so removing the binding to revoke one person would cut access for everyone matching it; the connector refuses that revoke instead of performing it. Remove those bindings in GCP directly. Subject and group bindings revoke normally, since each maps to exactly one identity or one group.Pool membership itself cannot be provisioned. GCP exposes no API to add or remove identities from a Workforce Identity pool — subjects and groups come from the identity provider’s assertion at sign-in. To change who reaches Google Cloud through a pool, manage the user or group in the upstream IdP (for example, in Microsoft Entra ID or Okta) and govern it in C1 through that connector, using the pool’s principalSet://…/group/… bindings for the mapping.Pools and providers have a lifecycle of their own. A pool can be created under an organization and deleted; a provider can be deleted from its pool. Deleting either is a soft delete: it stops authenticating immediately, but GCP keeps the record for 30 days, during which it can be restored in GCP and its ID cannot be reused. Deleting a pool cuts off every identity that signs in through it, not just one person’s access. Creating a provider is not offered: GCP requires the provider’s full OIDC or SAML configuration (issuer URI and client ID/secret, or the identity provider’s SAML metadata, plus the attribute mapping), which is not part of what C1 sends when it creates a resource, so it must be created in GCP. Providers hold no IAM policy of their own, so they have no entitlements or grants either way.

**IAM Role Assignments use the RBAC model. This resource type is opt-in and requires enabling the Cloud Infrastructure Access: Use RBAC option when configuring the connector. When enabled, IAM role assignments are synced as scope binding resources instead of flat grants on projects, folders, and organizations.

GCP IAM bindings can carry a condition (a CEL expression that GCP evaluates at request time, e.g. to grant access only during a time window or only for resources with a certain tag). On organizations, folders, and projects, both the flat-grants model and the IAM Role Assignments model show a conditional binding as access held, so a grant there can represent access GCP applies only while its condition holds — check the binding in GCP (Console or gcloud) when its exact, currently-in-effect state matters. On Workforce Identity pools, C1 also shows condition-scoped administrative access as the recovered role held, matching organizations, folders, and projects — check the binding in GCP when its currently-in-effect state matters. A pool Grant or Revoke rewrites the full policy after a GCP read that omits the CEL expression, so the connector cannot guarantee that an existing pool condition will be preserved by an otherwise unrelated provisioning operation.

Revoking conditional access on an organization, folder, or project deletes the condition. A condition is stored on the IAM binding itself, and GCP does not allow a binding with no members. So when a revoke removes the last member of a conditional binding, GCP deletes the binding and its CEL expression along with it — the same thing gcloud remove-iam-policy-binding does.The connector logs the full expression at WARN when this happens, so the connector logs are where the expression survives and can be recovered from. If a conditional binding’s CEL expression is something you need to keep, revoke that access directly in GCP rather than through C1, or ensure the binding retains at least one other member.On the IAM Role Assignments model, a grant writes an unconditional binding, so a principal who already holds the role under a condition ends up with unconditional access. On the flat-grants model, a grant joins an existing binding for that role — including a conditional one, when that is the binding already on the policy. A revoke targets the role, so it removes the principal from every binding for that role, conditional ones included. After a revoke that deleted the last member of a conditional binding, a re-grant writes a new unconditional binding. Manage those bindings in GCP when conditions are part of how you control access to an organization, folder, or project.

This connector can sync secrets and display them on the Inventory page. This connector syncs non-human identities and displays them on the Identities overview dashboard.

Gather Google Cloud Platform with Google Workspace credentials

Configuring the connector requires credentials from both Google Cloud Platform and the Google Workspace Admin console. You’ll complete the following steps:

Create a dedicated GCP project for the C1 integration
Enable the required APIs
Create a service account and assign it the necessary permissions
Download the service account’s JSON key
Grant the service account domain-wide delegation in the Google Workspace Admin console
Locate your primary domain and Customer ID

A user with the Super Admin role in Google Cloud Platform with Google Workspace must perform this task.

Create a new project

We recommend creating a dedicated GCP project for the C1 integration. This keeps the integration’s permissions and audit logs isolated from your other projects.

As a Google Cloud Platform with Google Workspace Super Admin, sign in to https://console.cloud.google.com.

In the toolbar, click the project select dropdown, and click NEW PROJECT.

Create a new project for your organization:

Project Name: Choose a name, such as “C1 Integration”
Organization/Location: Choose the appropriate Organization/Location

After the project is created, make sure the correct project is selected in the dropdown at the top.

Enable the APIs

In the navigation menu, navigate to APIs & Services > Library.

Search for each of the following APIs and click Enable:

Cloud Asset API
Cloud Resource Manager API
Identity and Access Management API
Admin SDK API

Optional: Sync secrets and buckets

Complete this section only if you want the connector to sync secrets (API keys, service account keys, Secret Manager secrets) or Cloud Storage buckets.

Secrets and bucket permissions are configured per project in GCP. If the connector is not filtering by project and the service account doesn’t have permissions across all projects, the sync will fail. We recommend using the Project IDs filter to explicitly specify which projects to sync.

Required organization-level role: Grant the service account the roles/cloudasset.viewer role at the organization level. This allows it to search resources across projects. Additional APIs to enable: Enable these APIs for each project you want to sync (or only for the projects specified in the Project IDs filter):

Secrets - API Keys: API Keys API
Secrets - Service account keys: IAM API
Secrets - Secret Manager secrets: Secret Manager API
Buckets: Cloud Storage API

Create a service account

In the navigation menu, navigate to APIs & Services > Credentials.

Select CREATE CREDENTIALS > Service Account.

Under Service account details, fill in the following:

Service account name: C1 Integration
Service account description: for example, “Service account for C1 Google Cloud Platform with Google Workspace Integration”

Click CREATE AND CONTINUE.

Under Grant this service account access to a project, assign the service account a role at the organization level. You can use the predefined Editor role, or create a custom role that includes only the permissions listed below.For READ access (syncing access data only), the role needs these permissions:

cloudasset.assets.analyzeIamPolicy
cloudasset.assets.searchAllIamPolicies
cloudasset.assets.searchAllResources
iam.roles.get
iam.roles.list
resourcemanager.folders.getIamPolicy
resourcemanager.folders.list
resourcemanager.organizations.get
resourcemanager.organizations.getIamPolicy
resourcemanager.projects.get
resourcemanager.projects.getIamPolicy
resourcemanager.projects.list
apikeys.keys.list
iam.serviceAccounts.list
iam.serviceAccountKeys.list
secretmanager.secrets.get
secretmanager.secrets.list
secretmanager.secrets.getIamPolicy
storage.buckets.list
storage.buckets.getIamPolicy
iam.workforcePools.list
iam.workforcePools.getIamPolicy
iam.workforcePoolProviders.get
iam.workforcePoolProviders.list

To also provision access (READ/WRITE), add these permissions to the role:

resourcemanager.folders.setIamPolicy
resourcemanager.organizations.setIamPolicy
resourcemanager.projects.setIamPolicy
secretmanager.secrets.setIamPolicy
storage.buckets.setIamPolicy
iam.workforcePools.setIamPolicy
iam.workforcePools.create
iam.workforcePools.get
iam.workforcePools.delete
iam.workforcePoolProviders.delete
iam.serviceAccountKeys.create
iam.serviceAccountKeys.delete

The iam.workforcePool* permissions are only needed when Workforce Identity Federation is enabled. iam.workforcePools.getIamPolicy belongs to the READ set because the pool’s own allow policy is what the connector reads to sync pool entitlements and grants — without it the sync fails rather than returning an empty pool. iam.workforcePools.setIamPolicy is only needed to grant and revoke those administrative roles. iam.workforcePools.create, iam.workforcePools.delete and iam.workforcePoolProviders.delete are only needed to create or delete the pools and providers themselves, and iam.workforcePools.get goes with them because creating or deleting a pool reads it back to confirm the result. Leave all four out to keep the connector able to govern access without being able to change the federation setup.

If you already had Workforce Identity Federation enabled, add iam.workforcePools.getIamPolicy to the role before upgrading. Earlier versions synced pools without reading their allow policy; the connector now reads it on every sync to produce each pool’s entitlements and grants. Without the permission the sync fails — deliberately, because reporting an empty policy instead would make C1 treat every pool grant it had already synced as revoked. The error names the permission to add.

iam.serviceAccountKeys.list is required when service-account key secret sync is enabled. Credential issuance additionally requires iam.serviceAccountKeys.create, and revoking a synced or issued key additionally requires iam.serviceAccountKeys.delete.

Leave Grant users access to this service account blank.

Click DONE.

Get credentials

Navigate back to APIs & Services > Credentials. Under Service Accounts, locate and click the service account you just created.

Click the service account’s email address. Locate and save the Unique ID — you’ll need it when configuring domain-wide delegation in the next section.

On the Service Account Details Page, click KEYS.

Click ADD KEY > Create new key.

Choose JSON and click CREATE. The new key is created and downloaded to your computer.

Keep the downloaded file safe — you’ll upload it when configuring the connector in C1.

Add the service account to Google Workspace

Domain-wide delegation allows the GCP service account to access Google Workspace data — directory users, groups, roles, and audit logs — on behalf of your organization. You configure this in the Google Workspace Admin console at https://admin.google.com, which is separate from the Google Cloud console.

Go to https://admin.google.com as a SUPER ADMIN.

In the navigation menu, select Security > Access and data control > API Controls.

Click MANAGE DOMAIN WIDE DELEGATION.

Click Add new and fill out the form:

Client ID: The Unique ID you saved from the service account details page

OAuth Scopes: Copy and paste in the relevant scopes

Use the following scopes to give C1 READ access (syncing access data):

https://www.googleapis.com/auth/admin.directory.user.alias.readonly,https://www.googleapis.com/auth/admin.directory.rolemanagement.readonly,https://www.googleapis.com/auth/admin.directory.group.member.readonly,https://www.googleapis.com/auth/admin.directory.group.readonly,https://www.googleapis.com/auth/admin.directory.user.readonly,https://www.googleapis.com/auth/admin.directory.domain.readonly,https://www.googleapis.com/auth/admin.reports.audit.readonly

Use the following scopes to give C1 READ/WRITE access (syncing access data and provisioning access):

https://www.googleapis.com/auth/admin.directory.user.alias.readonly,https://www.googleapis.com/auth/admin.directory.rolemanagement,https://www.googleapis.com/auth/admin.directory.group.member,https://www.googleapis.com/auth/admin.directory.group,https://www.googleapis.com/auth/admin.directory.user.readonly,https://www.googleapis.com/auth/admin.directory.domain.readonly,https://www.googleapis.com/auth/admin.reports.audit.readonly

Click AUTHORIZE.

In the navigation menu, select Account > Account Settings.

Copy and save the Customer ID from this page.

Locate your primary domain

In the navigation panel on the left, click Account > Domains.

Click Manage Domains. Locate and copy the domain labeled as the Primary Domain in the Type column.

Before moving on, confirm you have the following ready for the connector configuration:

Customer ID (from Account Settings)
Primary domain (from Manage Domains)
Administrator email — the email address of a super admin for your domain
JSON credentials file — the service account key downloaded in the Get credentials section

Configure the Google Cloud Platform with Google Workspace connector

To complete this task, you’ll need:

The Connector Administrator or Super Administrator role in C1
Access to the set of Google Cloud Platform with Google Workspace credentials generated by following the instructions above

Cloud-hosted
Self-hosted

Follow these instructions to use a built-in, no-code connector hosted by C1.

In C1, navigate to Apps > Connectors and click Add connector.

Search for Google Cloud Platform with Google Workspace and click Add.

Choose where to add the connector: Create a new app, or Add to an existing app (then select the app).If you’re creating a new app, choose whether to link it to an application discovered from your identity provider: select Yes and pick the IdP application, or No to continue with just the connector.

Set the connector’s Name and, optionally, a Description.

Click the pencil icon next to Owners to choose who can configure and manage this connector.

Click Add. The connector is created and its configuration page opens.

Find the Settings area of the page and click Edit.

In the Customer ID field, enter the customer ID.

In the Domain field, enter the primary domain.

In the Administrator email field, enter the email address of a super admin for your domain.

In the Credentials (JSON) area, click Choose file and upload the JSON key file.

Optional. Check the box if you want to skip syncing Google Cloud Platform system accounts.

Optional. Uncheck the box (which is checked by default) if you want to sync Google Cloud Platform default projects.

Optional. In the Project IDs field, enter a list of project IDs to limit the connector’s sync to only those projects. Be sure to enter project IDs, not project names.

Optional. Check the box to Enable Workforce Identity Federation, which allows the connector to sync Workforce Identity pools and pool providers.

Enter the Workforce Identity Pool ID and Workforce Identity Pool Provider ID. The connector reads the provider’s google.subject attribute mapping to work out which identity provider claim to write when it grants a federated user access, so these must point at the pool and provider your users actually sign in through. Revoking a synced grant targets the pool recorded on the binding it was synced from. If a Shared identity source matches the same identity through multiple pools, the safeguard described above prevents removing only one binding while another keeps granting access.

If you enable Workforce Identity Federation, complete the Shared identity source configuration in the next step before finishing.

By default, the connector only syncs roles that are assigned to an IAM policy. These settings allow you to configure the connector to sync roles regardless of their IAM policy status.

Optional. Check the box to Always sync custom roles.
Optional. In the List of role IDs to always sync field, enter a list of role IDs that should be synced. Be sure to enter role IDs, not role names.

Optional. Check the box to Cloud Infrastructure Access: Use RBAC to enable the RBAC model for IAM role assignments. When enabled, role assignments are synced as scope binding resources (IAM Role Assignments) instead of flat grants on projects, folders, and organizations. This also enables provisioning of IAM role assignments via the scope binding model.

Enabling this option changes how IAM access data is represented in C1. Flat grants on projects, folders, and organizations will no longer be synced — only the IAM Role Assignment resources will carry that data. Enable this only if your C1 configuration is set up to use the RBAC model.

Click Save.

If you enabled Workforce Identity Federation, complete this additional configuration:

In the Shared identity source area of the page, click Edit.
Select the connector from which you want to pull identities.
Optional. Limit the identities pulled from the connector you selected to only those with a certain entitlement by setting the entitlement.
Click Save.

The connector’s label changes to Syncing, followed by Connected. You can view the logs to ensure that information is syncing.

Done. Your Google Cloud Platform with Google Workspace connector is now pulling access data into C1.

Follow these instructions to use the Google Cloud Platform with Google Workspace connector, hosted and run in your own environment.When running in service mode on Kubernetes, a self-hosted connector maintains an ongoing connection with C1, automatically syncing and uploading data at regular intervals. This data is immediately available in the C1 UI for access reviews and access requests.

Resources

Official download center: For stable binaries (Windows/Linux/macOS) and container images.

Step 1: Set up a new Google Cloud Platform with Google Workspace connector

In C1, navigate to Apps > Connectors and click Add connector.

Search for Baton and click Add.

Set the connector’s Name and, optionally, a Description.

Click the pencil icon next to Owners to choose who can configure and manage this connector.

Click Add. The connector is created and its configuration page opens.

In the Settings area of the page, click Edit.

Click Rotate to generate a new Client ID and Secret.Carefully copy and save these credentials. We’ll use them in Step 2.

Step 2: Create Kubernetes configuration files

Create two Kubernetes manifest files for your Google Cloud Platform with Google Workspace connector deployment:

Secrets configuration

# baton-google-cloud-platform-secrets.yaml
apiVersion: v1
kind: Secret
metadata:
  name: baton-google-cloud-platform-secrets
type: Opaque
stringData:
  # C1 credentials
  BATON_CLIENT_ID: <C1 client ID>
  BATON_CLIENT_SECRET: <C1 client secret>

  # Google Cloud Platform with Google Workspace credentials
  BATON_CUSTOMER_ID: <customer ID>
  BATON_DOMAIN: <domain>
  BATON_ADMIN_EMAIL: <admin email>
  BATON_CREDENTIALS_JSON: <service account credentials JSON>

  # Optional: include if you want C1 to provision access using this connector
  BATON_PROVISIONING: true

  # Optional: include to skip Google-managed system accounts
  BATON_SKIP_SYSTEM_ACCOUNTS: true

  # Optional: include to sync Cloud Storage buckets (requires the storage.buckets.list permission)
  BATON_SYNC_BUCKETS: true

  # Optional: include to sync API keys and service account keys
  BATON_SYNC_SECRETS: true

  # Optional: include to sync Secret Manager secrets (requires the Secret Manager API)
  BATON_SYNC_SECRET_MANAGER_SECRETS: true

  # Optional: include to always sync custom roles, even without assignments
  BATON_ALWAYS_SYNC_CUSTOM_ROLES: true

  # Optional: include to enable workforce identity federation support
  BATON_ENABLE_WORKFORCE_IDENTITY_FEDERATION: true
  BATON_WORKFORCE_IDENTITY_POOL_ID: <workforce identity pool ID>
  BATON_WORKFORCE_IDENTITY_POOL_PROVIDER_ID: <workforce identity pool provider ID>

  # Optional: include to limit sync to specific projects (enter project IDs, not names)
  BATON_PROJECT_FILTER: <comma-separated list of project IDs>

  # Optional: Include to always sync specific roles (enter role IDs, not names)
  BATON_ALWAYS_SYNC_ROLES_FILTER: <comma-separated list of role IDs>

  # Optional: include to use the RBAC model for IAM role assignments.
  # When enabled, role assignments are synced as scope binding resources instead of
  # flat grants on projects, folders, and organizations.
  BATON_USE_RBAC: true

See the connector’s README or run --help to see all available configuration flags and environment variables.

Deployment configuration

# baton-google-cloud-platform.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: baton-google-cloud-platform
  labels:
    app: baton-google-cloud-platform
spec:
  selector:
    matchLabels:
      app: baton-google-cloud-platform
  template:
    metadata:
      labels:
        app: baton-google-cloud-platform
        baton: true
        baton-app: google-cloud-platform
    spec:
      containers:
        - name: baton-google-cloud-platform
          image: public.ecr.aws/conductorone/baton-google-cloud-platform:latest
          imagePullPolicy: IfNotPresent
          env:
            - name: BATON_HOST_ID
              value: baton-google-cloud-platform
          envFrom:
            - secretRef:
                name: baton-google-cloud-platform-secrets

Step 3: Deploy the connector

Create a namespace in which to run C1 connectors (if desired), then apply the secret config and deployment config files.

Check that the connector data uploaded correctly. In C1, click Apps. On the Managed apps tab, locate and click the name of the application you added the Google Cloud Platform with Google Workspace connector to. Data should be found on the Entitlements and Accounts tabs.

Done. Your Google Cloud Platform with Google Workspace connector is now pulling access data into C1.

Welcome

Manage connectors

Deploy connectors

Upload connector data

Configurable connectors

Pre-built connectors

Set up a Google Cloud Platform with Google Workspace connector

Capabilities

Gather Google Cloud Platform with Google Workspace credentials

Create a new project

Enable the APIs

Optional: Sync secrets and buckets

Create a service account

Get credentials

Add the service account to Google Workspace

Locate your primary domain

Configure the Google Cloud Platform with Google Workspace connector

Resources

Step 1: Set up a new Google Cloud Platform with Google Workspace connector

Step 2: Create Kubernetes configuration files

Secrets configuration

Deployment configuration

Step 3: Deploy the connector

​Capabilities

​Gather Google Cloud Platform with Google Workspace credentials

​Create a new project

​Enable the APIs

​Optional: Sync secrets and buckets

​Create a service account

​Get credentials

​Add the service account to Google Workspace

​Locate your primary domain

​Configure the Google Cloud Platform with Google Workspace connector

​Resources

​Step 1: Set up a new Google Cloud Platform with Google Workspace connector

​Step 2: Create Kubernetes configuration files

​Secrets configuration

​Deployment configuration

​Step 3: Deploy the connector

Capabilities

Gather Google Cloud Platform with Google Workspace credentials

Create a new project

Enable the APIs

Optional: Sync secrets and buckets

Create a service account

Get credentials

Add the service account to Google Workspace

Locate your primary domain

Configure the Google Cloud Platform with Google Workspace connector

Resources

Step 1: Set up a new Google Cloud Platform with Google Workspace connector

Step 2: Create Kubernetes configuration files

Secrets configuration

Deployment configuration

Step 3: Deploy the connector