> ## Documentation Index
> Fetch the complete documentation index at: https://conductorone-paul-querna-mcp-sources-docs.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Set up a Google Cloud Platform with Google Workspace connector
> C1 provides identity governance and just-in-time provisioning for Google Cloud Platform with Google Workspace. Integrate your Google Cloud Platform with Google Workspace instance with C1 to run user access reviews (UARs) and enable just-in-time access requests.
## 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](/product/admin/inventory) and display them on the **Inventory** page.
[This connector syncs non-human identities](/product/admin/nhi) 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:
1. Create a dedicated GCP project for the C1 integration
2. Enable the required APIs
3. Create a service account and assign it the necessary permissions
4. Download the service account's JSON key
5. Grant the service account domain-wide delegation in the Google Workspace Admin console
6. 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](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:
```bash theme={null}
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:
```bash theme={null}
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](https://admin.google.com), which is separate from the Google Cloud console.
Go to [https://admin.google.com](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):
```bash theme={null}
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):
```bash theme={null}
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
**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.
1. **Optional.** Check the box to **Always sync custom roles**.
2. **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:
1. In the **Shared identity source** area of the page, click **Edit**.
2. Select the connector from which you want to pull identities.
3. **Optional.** Limit the identities pulled from the connector you selected to only those with a certain entitlement by setting the entitlement.
4. 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](https://dist.conductorone.com/ConductorOne/baton-google-cloud-platform): 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**.
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.
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
```yaml expandable theme={null}
# 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:
BATON_CLIENT_SECRET:
# Google Cloud Platform with Google Workspace credentials
BATON_CUSTOMER_ID:
BATON_DOMAIN:
BATON_ADMIN_EMAIL:
BATON_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:
BATON_WORKFORCE_IDENTITY_POOL_PROVIDER_ID:
# Optional: include to limit sync to specific projects (enter project IDs, not names)
BATON_PROJECT_FILTER:
# Optional: Include to always sync specific roles (enter role IDs, not names)
BATON_ALWAYS_SYNC_ROLES_FILTER:
# 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
```yaml expandable theme={null}
# 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.