# Google Cloud ### Overview The Veza Integration for Google Cloud Platform (GCP) enables discovery of Google Cloud Workspace and Google Cloud IAM entities, along with authorization metadata for the organization, projects, and folders. Veza additionally discovers authorization to resources such as Storage, Compute, BigQuery, and KMS, using read-only permissions and native project APIs. {% hint style="info" %} **Native Identity Mapping**: If you have Okta integrated with a Google Workspace application, Veza automatically creates identity relationships to Google Workspace users and groups based on email matching. Custom identity mapping is only needed for other integration combinations. See [Custom Identity Mappings](/4yItIzMvkpAvMVFAamTf/integrations/configuration/custom-identity-mappings.md#native-vs-custom-identity-mappings) for details. {% endhint %} ### Supported services Veza extracts the following Google Cloud services. Use the **Limit Services** option when configuring the integration to enable only the services needed — see [Limiting Extractions](/4yItIzMvkpAvMVFAamTf/integrations/configuration/limits.md#limit-services). Google Cloud IAM and Google Workspace are always extracted and cannot be disabled. * **Artifact Registry**: Repositories, packages * **BigQuery**: Datasets, tables * **Cloud Key Management Service (KMS)**: Key rings, crypto keys * **Cloud Run**: Services, instances * **Cloud SQL**: Database instances, databases, users * **Cloud Storage**: Buckets, objects, folders * **Compute Engine**: VMs, VPCs, subnets, network interfaces * **GCP Databricks**: Workspaces, accounts, schemas * **Google Kubernetes Engine**: Clusters * **Secret Manager**: Secrets, secret versions * **Vertex AI**: Models, endpoints, reasoning engines * **Workload Identity Federation**: Identity pools, providers ### Prerequisites Before starting the integration setup: * You need Workspace super admin permissions to create and assign custom admin roles * You need administrator access to the Google Cloud Organization * For Workload Identity Federation: The AWS Role ARN will be displayed in the Veza integration configuration form {% hint style="warning" %} **Organization-Level Access Required**: The Google Cloud integration requires access to a Google Cloud Organization. Project-only setups are not supported. You must have organization-level administrator permissions to configure roles and bindings at the organization level, which will grant access to all projects and folders within the organization. {% endhint %} > See [Notes & Supported Entities](/4yItIzMvkpAvMVFAamTf/integrations/integrations/google/google-info.md) for details on the Veza-Google connector and supported services. ### Authentication Methods Veza supports two methods for authenticating with Google Cloud: 1. **Workload Identity Federation (Recommended)** * Eliminates the need to manage service account keys * Uses temporary credentials through AWS-Google Cloud trust * Follows Google Cloud security best practices 2. **Service Account Key Authentication (Alternative)** * Traditional method using service account key files * Use only when Workload Identity Federation cannot be implemented
Option 1: Workload Identity Federation (Recommended) Workload Identity Federation allows Veza to access Google Cloud resources securely without storing long-lived credentials. It uses a trust relationship between Veza's AWS role and your Google Cloud service account. Integration Flow: 1. Veza's AWS role requests access to Google Cloud resources. 2. AWS generates a signed token proving Veza's identity. 3. Google Cloud validates the token via the established trust relationship. 4. Google Cloud issues temporary credentials for the service account. 5. Veza uses these temporary credentials to access authorized resources. To enable Workload Identity Federation, enable the required APIs for your Google Cloud project, then create a Workload Identity Pool and configure AWS as the identity provider. After configuring service account impersonation to grant access to Veza's AWS role, you can download the credential configuration file for integration setup. **Prerequisites** 1. Retrieve Veza's AWS Role ARN: * When configuring a Google Cloud integration in Veza, the full Assume Role ARN is displayed at the top of the configuration form. * Copy this ARN, as you will need the **AWS Account ID** and **Role Name** from it to configure the integration in Google Cloud. * Example ARN format: `arn:aws:iam::064704382911:role/tenant1-insight-point` 2. Complete the common Google Cloud setup steps (excluding service account key creation): * Enable domain-wide delegation. * Create and assign a custom admin role. * Create and bind an organizational role. * Enable required APIs. **Step 1: Create Service Account** 1. Navigate to **IAM & Admin** > [**Service Accounts**](https://console.cloud.google.com/iam-admin/serviceaccounts) 2. Click **Create Service Account** 3. Provide a name, ID, and description 4. Note the service account email address Creating a GCP service account **Step 2: Enable Required APIs** Enable the following APIs for your Google Cloud project: * IAM API * Cloud Resource Manager API * IAM Service Account Credentials API * Security Token Service API **Step 3: Create Workload Identity Pool** To create a pool, choose **IAM & Admin** > **Workload Identity Federation** from the Google Cloud Console. Follow these steps to add a pool for the Veza integration: 1. In the Google Cloud console, go to **New workload provider and pool** 2. Provide a pool name (e.g., `veza-federation-pool`) 3. Add a description 4. Click **Continue** **Step 4: Add AWS as Identity Provider** 1. Select **AWS** as the provider 2. Configure the provider details: * **Provider name**: e.g., `Veza AWS Provider` * **Provider ID**: Add a unique identifier, e.g. `veza-aws-prod` * **AWS Account ID**: Enter the AWS account ID from the role ARN shown in the Veza configuration form, e.g., `064704382911` 3. Click **Continue** 4. Configure the attribute mapping to extract the role name from Veza's AWS ARN: * For Google field: enter `attribute.aws_role` * For AWS field: enter `assertion.arn.extract('assumed-role/{role}/')` 5. Under 'Attribute Conditions', add: ```txt attribute.aws_role == 'ROLE_NAME' ``` Replace `ROLE_NAME` with your Veza integration role name. > **Note**: The attribute mappings transform AWS role information into a format Google Cloud can use, while the condition acts as a security control by only allowing the specific Veza integration role to use this federation. This prevents any other AWS roles from accessing your Google Cloud resources. 6. Click **Save** **Step 5: Configure Service Account Impersonation** 1. Go to the pool details page 2. Select **Grant Access** 3. In the dialog, select **Grant access using Service Account impersonation** 4. Choose the service account created for the Veza integration from the **Select service account** dropdown 5. Under **Select Principals**: 1. Choose "AWS Role" as the attribute name 2. Enter only the **role name** (not the full ARN) as the attribute value. The Veza configuration form shows the full ARN; you must enter only the final segment. For example, for `arn:aws:iam::123456789012:role/veza-integration-role`, enter `veza-integration-role`. 6. Click **Save** and **Dismiss** **Step 6: Download Configuration** 1. On the provider details page, select **Connected service accounts** 2. Find the integration service account and click **Download** 3. Select the AWS provider and click **Download config** The configuration file will look similar to: ```json { "universe_domain": "googleapis.com", "type": "external_account", "audience": "//iam.googleapis.com/projects//locations/global/workloadIdentityPools//providers/", "subject_token_type": "urn:ietf:params:aws:token-type:aws4_request", "token_url": "https://sts.googleapis.com/v1/token", "credential_source": { "environment_id": "aws1", "regional_cred_verification_url": "https://sts.{region}.amazonaws.com?Action=GetCallerIdentity&Version=2011-06-15" } } ``` Save this file for use in the Veza integration setup. See [Google's Workload Identity Federation Documentation](https://cloud.google.com/iam/docs/workload-identity-federation-with-other-clouds) for detailed instructions. **Troubleshooting** If you encounter a `403: Not Authorized to access this resource/api` error during privilege extraction, the attribute value in the service account impersonation condition is likely set to the full AWS Role ARN instead of the role name. To fix this: 1. In the Google Cloud Console, go to **IAM & Admin** > **Workload Identity Federation**. 2. Open the pool and select the AWS provider. 3. Select **Connected service accounts** and open the impersonation condition for the Veza service account. 4. Under **Select Principals**, confirm the attribute value is set to the role name only (for example, `veza-integration-role`), not the full ARN. 5. Update the value if needed and click **Save**. If you encounter the error `Permission 'iam.serviceAccounts.getAccessToken' denied on resource (or it may not exist)`, follow these steps: 1. Enable audit logging for Workload Identity Federation: * Go to **IAM & Admin --> Audit Logs** in the Google Cloud Console * Find the project where you configured Workload Identity Federation * Enable audit logging for "Identity and Access Management (IAM) API" 2. Check STS token exchange logs in Log Explorer: * Open **Observability-->Logging** * Set the resource to `audited_resource` * Filter for `resource.labels.service="sts.googleapis.com"` * Look for `principalSubject` in the logs to verify the AWS role ARN attempting federation Example log entry: `principalSubject: "arn:aws:sts::123456789012:assumed-role/veza-integration-role/veza-gcp-federation"` Using logs to identify the Veza role ARN The log explorer will show whether the correct AWS role is attempting access and help identify any misconfigurations in the identity pool settings. For more details about Workload Identity Federation audit logging, see [Google's Audit Logging Documentation](https://cloud.google.com/iam/docs/audit-logging/examples-workload-identity).
Option 2: Service Account Key Authentication (Alternative) This traditional method uses a service account key for authentication. While supported, it should only be used when Workload Identity Federation cannot be implemented. **Step 1: Create Service Account** 1. Navigate to **IAM & Admin** > [**Service Accounts**](https://console.cloud.google.com/iam-admin/serviceaccounts) 2. Click **Create Service Account** 3. Provide a name, ID, and description 4. Note the service account email address Creating a GCP service account **Step 2: Generate Service Account Key** 1. Go to [Service Accounts](https://console.cloud.google.com/iam-admin/serviceaccounts) 2. Select your project 3. Click the **Keys** tab 4. Select **Create New Key** 5. Choose JSON format 6. Download and securely store the key file **Note**: If you receive a message about `iam.disableServiceAccountKeyCreation` being enforced, you may need to modify your organization policy to allow key creation.
## Required Configuration Steps Complete these steps regardless of your chosen authentication method. #### Enable Google Cloud APIs To discover complete authorization metadata for Google Cloud, the project containing the integration service account must have the following data APIs enabled. Click the **Enable API** links in the following list to enable each API. Ensure that the project where you created the service account is selected before enabling the API. > You can also enable APIs for each project to discover by opening Google Cloud console **API Library** page, and choosing the Google Cloud project where the service account resides. Use the **Search for APIs & Services** find and enable APIs for the services to discover. **Mandatory APIs** These APIs must be enabled in your project: * **Cloud Resource Manager API** ([Enable API](https://console.cloud.google.com/apis/library/cloudresourcemanager.googleapis.com)) * Required for organization, project, and folder discovery * **Cloud Identity API** ([Enable API](https://console.developers.google.com/apis/api/cloudidentity.googleapis.com)) * Required for identity management * **Admin SDK API** ([Enable API](https://console.developers.google.com/apis/api/admin.googleapis.com/overview)) * Required for workspace administration * **Groups Settings API** ([Enable API](https://console.cloud.google.com/apis/api/groupssettings.googleapis.com/overview)) * Required for group management * **Identity and Access Management (IAM) API** ([Enable API](https://console.developers.google.com/apis/api/iam.googleapis.com)) * Required for identity and access management * (Optional) IAM API v2 to discover Deny Policies and use `iam.denypolicies.get` and `iam.denypolicies.list` permissions **Optional APIs** Enable these APIs based on the services you want to discover: * **Service Usage API** ([Enable API](https://console.cloud.google.com/apis/library/serviceusage.googleapis.com)) * **Cloud Storage API** ([Enable API](https://console.cloud.google.com/apis/library/storage.googleapis.com)) * **KMS API** ([Enable API](https://console.cloud.google.com/apis/library/cloudkms.googleapis.com)) * **BigQuery API** ([Enable API](https://console.cloud.google.com/apis/library/bigquery.googleapis.com)) * **Compute Engine API** ([Enable API](https://console.cloud.google.com/apis/library/compute.googleapis.com)) * **Cloud Run Admin API** ([Enable API](https://console.cloud.google.com/apis/library/run.googleapis.com)) * **Kubernetes Engine API** ([Enable API](https://console.cloud.google.com/apis/library/container.googleapis.com)) * **Cloud SQL Admin API** ([Enable API](https://console.cloud.google.com/apis/library/sqladmin.googleapis.com)) * **Secret Manager API** ([Enable API](https://console.cloud.google.com/apis/library/secretmanager.googleapis.com)) * **Vertex AI API** ([Enable API](https://console.cloud.google.com/apis/library/aiplatform.googleapis.com)) * **Artifact Registry API** ([Enable API](https://console.cloud.google.com/apis/library/artifactregistry.googleapis.com)) #### Enable Domain-Wide Delegation 1. From your Google Workspace domain's [Admin console](http://admin.google.com), choose **Security** > **Access and data control** > **API controls** 2. Under **Domain wide delegation**, select **Manage Domain Wide Delegation** 3. Click **Add new** ![Enabling domain wide delegation](/files/DWwtKPYROcBHZ6Jz5Vuj) 4. Enter the service account's client ID 5. Add these OAuth scopes: ```plaintext https://www.googleapis.com/auth/admin.directory.user.readonly https://www.googleapis.com/auth/admin.directory.domain.readonly https://www.googleapis.com/auth/admin.directory.rolemanagement.readonly https://www.googleapis.com/auth/apps.groups.settings ``` 6. Click **Authorize** #### Create a Custom Admin Role You'll need to create a custom Workspace role with the required API permissions, and assign the role to the integration service account: 1. In Admin console, go to **Admin roles**. You may need to click "show more" on the home page for the option to appear: ![Creating a custom admin role](/files/UzFESzy5nZpUQMa7DVvJ) 2. Click **Create new role** 3. Enter a name and description 4. Under Admin API Privileges, enable: * Users > Read * Groups > Read * Organization Units > Read After creating the role, assign it to your service account: 1. On the role Admins panel, choose *Assign role* > *Assign service accounts* 2. Enter the email address of the service account ![Assign workspace role](/files/PekDSkzmgvSG3aSu6RrT) For more information, see [Assign specific admin roles - Google Workspace Admin Help](https://support.google.com/a/answer/9807615). #### Permission requirements by feature The permissions needed by the Veza service account depend on which features are enabled for the integration: | Feature | Permissions Required | | -------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Extraction (all customers) | IAM read permissions + service-specific read permissions documented below | | Lifecycle Management | Google Workspace Directory API OAuth scopes — no additional IAM permissions required. See [Provisioning](/4yItIzMvkpAvMVFAamTf/integrations/integrations/google/provisioning.md) | {% hint style="info" %} The `required_permissions` list returned by the [Check Google Cloud Permissions](/4yItIzMvkpAvMVFAamTf/integrations/integrations/google/check-google-cloud-permissions.md) API currently includes write-level Secret Manager permissions that Veza does not use. You can safely ignore any `secretmanager` write permissions flagged as missing. See [Check Google Cloud Permissions](/4yItIzMvkpAvMVFAamTf/integrations/integrations/google/check-google-cloud-permissions.md) for details. {% endhint %} #### Create an Organization Role From your Google Cloud console, create a role to bind to the Veza service account. You can create this role using the UI, or the [Google Cloud CLI](#working-with-the-google-cloud-cli). Go to **IAM & Admin**, and select **Roles** from the menu on the left side. When creating the organization role, ensure your Organization (not an individual project) is selected: ![Confirm that the organization is active, and change if needed.](/files/IK4nXwjfWTrZFd6s8iQE) Create a role in Google Cloud Organization with these minimum permissions: ```txt iam.roles.get iam.roles.list iam.serviceAccounts.list iam.serviceAccounts.signJwt iam.denypolicies.get iam.denypolicies.list resourcemanager.folders.getIamPolicy resourcemanager.folders.list resourcemanager.organizations.get resourcemanager.organizations.getIamPolicy resourcemanager.projects.getIamPolicy resourcemanager.projects.list resourcemanager.projects.get serviceusage.services.list resourcemanager.tagValues.list resourcemanager.tagValues.get resourcemanager.tagKeys.list resourcemanager.tagKeys.get compute.instances.listTagBindings storage.buckets.listTagBindings bigquery.datasets.listTagBindings bigquery.tables.listTagBindings cloudkms.keyRings.listTagBindings run.services.listTagBindings cloudsql.instances.listTagBindings secretmanager.secrets.listTagBindings ``` > **Important**: The permissions list includes resource-specific tag binding permissions (e.g., `compute.instances.listTagBindings`, `storage.buckets.listTagBindings`) which replaced the deprecated `resourcemanager.resourceTagBindings.list` permission. If you previously used `resourcemanager.resourceTagBindings.list`, you should remove it and use the resource-specific permissions instead. These resource-specific permissions are required to discover tags attached to GCP resources. #### Bind the Role to the Service Account After creating the role, bind it to the integration service account: 1. From the **IAM & Admin** page of the Google console, click *IAM* 2. Ensure that your Organization (***not an individual Project***) is active in the top left corner 3. Click *+ Grant Access* to apply the role to the Veza service account: * Enter the service account email in the *New Principals* field * Under *Select a Role*, pick "Custom" and specify the Veza role This will grant the service account the required permissions for the current organization and its children (all Projects and Folders). > **Important:** The base role above provides core extraction functionality. To enable discovery of specific Google Cloud services (Storage, Compute, BigQuery, KMS, Secret Manager, etc.), you must also enable APIs and add the permissions from the "Additional Service Permissions" section below based on the services you want to discover. #### Working with the Google Cloud CLI You can create this role using the Google Cloud CLI: {% code overflow="wrap" lineNumbers="true" %} ```sh gcloud iam roles create VEZA_ROLE_NAME --organization=YOUR_ORG_ID --permissions=\ iam.roles.get,\ iam.roles.list,\ iam.serviceAccounts.list,\ iam.serviceAccounts.signJwt,\ iam.denypolicies.get,\ iam.denypolicies.list,\ resourcemanager.folders.getIamPolicy,\ resourcemanager.folders.list,\ resourcemanager.organizations.get,\ resourcemanager.organizations.getIamPolicy,\ resourcemanager.projects.getIamPolicy,\ resourcemanager.projects.list,\ resourcemanager.projects.get,\ serviceusage.services.list,\ resourcemanager.tagValues.list,\ resourcemanager.tagValues.get,\ resourcemanager.tagKeys.list,\ resourcemanager.tagKeys.get,\ compute.instances.listTagBindings,\ storage.buckets.listTagBindings,\ bigquery.datasets.listTagBindings,\ bigquery.tables.listTagBindings,\ cloudkms.keyRings.listTagBindings,\ run.services.listTagBindings,\ cloudsql.instances.listTagBindings,\ secretmanager.secrets.listTagBindings,\ storage.buckets.getIamPolicy,\ storage.buckets.list,\ compute.instances.list,\ compute.instances.getIamPolicy,\ compute.networks.list,\ compute.regions.list,\ compute.subnetworks.getIamPolicy,\ compute.subnetworks.list,\ compute.zones.list,\ cloudkms.locations.get,\ cloudkms.locations.list,\ cloudkms.cryptoKeyVersions.get,\ cloudkms.cryptoKeyVersions.list,\ cloudkms.cryptoKeyVersions.viewPublicKey,\ cloudkms.cryptoKeys.getIamPolicy,\ cloudkms.cryptoKeys.get,\ cloudkms.cryptoKeys.list,\ cloudkms.keyRings.get,\ cloudkms.keyRings.list,\ cloudkms.keyRings.getIamPolicy,\ bigquery.datasets.getIamPolicy,\ bigquery.datasets.get,\ bigquery.tables.getIamPolicy,\ bigquery.tables.get,\ bigquery.tables.list,\ run.services.list,\ run.services.getIamPolicy,\ run.locations.list,\ cloudsql.instances.list,\ cloudsql.users.list,\ cloudsql.databases.list,\ container.clusters.list,\ secretmanager.secrets.list,\ secretmanager.secrets.get,\ secretmanager.secrets.getIamPolicy,\ secretmanager.versions.list,\ secretmanager.versions.get,\ secretmanager.locations.get,\ secretmanager.locations.list,\ secretmanager.secrets.listEffectiveTags,\ secretmanager.secrets.listTagBindings,\ artifactregistry.locations.list,\ artifactregistry.repositories.list,\ artifactregistry.repositories.getIamPolicy,\ artifactregistry.packages.list,\ logging.logEntries.list ``` {% endcode %} To run `gcloud` commands, install the SDK, or open the CLI from the web console: ![Opening the gcloud console](/files/2FTerH7pNBrUfSUeC03s) To add additional permissions later (if new functionality is required), use: ```sh gcloud iam roles update <> --organization=<> --add-permissions=<> ``` #### Additional Service Permissions * **Storage Buckets** * **Required Permissions:** * `storage.buckets.getIamPolicy` * `storage.buckets.list` * `storage.buckets.listTagBindings` * **Required API:** [Cloud Storage API](https://console.cloud.google.com/apis/library/storage.googleapis.com) * **Compute** * **Required Permissions:** * `compute.instances.list` * `compute.instances.getIamPolicy` * `compute.instances.listTagBindings` * `compute.networks.list` * `compute.regions.list` * `compute.subnetworks.getIamPolicy` * `compute.subnetworks.list` * `compute.zones.list` * **Required API:** [Compute Engine API](https://console.cloud.google.com/apis/library/compute.googleapis.com) * **Key Management** * **Required Permissions:** * `cloudkms.cryptoKeyVersions.get` * `cloudkms.cryptoKeyVersions.list` * `cloudkms.cryptoKeyVersions.viewPublicKey` * `cloudkms.cryptoKeys.get` * `cloudkms.cryptoKeys.list` * `cloudkms.cryptoKeys.getIamPolicy` * `cloudkms.keyRings.get` * `cloudkms.keyRings.list` * `cloudkms.keyRings.getIamPolicy` * `cloudkms.keyRings.listTagBindings` * `cloudkms.locations.get` * `cloudkms.locations.list` * **Required API:** [KMS API](https://console.cloud.google.com/apis/library/cloudkms.googleapis.com) * **BigQuery** * **Required Permissions:** * `bigquery.datasets.getIamPolicy` * `bigquery.datasets.get` * `bigquery.datasets.listTagBindings` * `bigquery.tables.getIamPolicy` * `bigquery.tables.get` * `bigquery.tables.list` * `bigquery.tables.listTagBindings` * **Required Permissions for Activity Monitoring:** * `logging.logEntries.list` * `logging.privateLogEntries.list` * **Required API:** [BigQuery API](https://console.cloud.google.com/apis/library/bigquery.googleapis.com) * **Cloud Run** * **Required Permissions:** * `run.services.list` * `run.services.getIamPolicy` * `run.services.listTagBindings` * `run.locations.list` * **Required API:** [Cloud Run Admin API](https://console.cloud.google.com/apis/library/run.googleapis.com) * **Cloud SQL** * **Required Permissions:** * `cloudsql.instances.list` * `cloudsql.instances.listTagBindings` * `cloudsql.users.list` * `cloudsql.databases.list` * **Required API:** [Cloud SQL Admin API](https://console.cloud.google.com/apis/library/sqladmin.googleapis.com) * **Kubernetes Engine** * **Required Permissions:** `container.clusters.list` * **Required API:** [Kubernetes Engine API](https://console.cloud.google.com/apis/library/container.googleapis.com) * **Secret Manager** * **Required Permissions:** * `secretmanager.secrets.list` * `secretmanager.secrets.get` * `secretmanager.secrets.getIamPolicy` * `secretmanager.versions.list` * `secretmanager.versions.get` * `secretmanager.locations.get` * `secretmanager.locations.list` * `secretmanager.secrets.listEffectiveTags` * `secretmanager.secrets.listTagBindings` * **Required API:** [Secret Manager API](https://console.cloud.google.com/apis/library/secretmanager.googleapis.com) * **Vertex AI** * **Required Permissions:** * `aiplatform.locations.list` * `aiplatform.reasoningEngines.list` * `aiplatform.reasoningEngines.get` * `aiplatform.endpoints.list` * `aiplatform.endpoints.getIamPolicy` * `aiplatform.models.list` * **Required API:** [Vertex AI API](https://console.cloud.google.com/apis/library/aiplatform.googleapis.com) * **Artifact Registry** * **Required Permissions:** * `artifactregistry.locations.list` * `artifactregistry.repositories.list` * `artifactregistry.repositories.getIamPolicy` * `artifactregistry.packages.list` * **Required API:** [Artifact Registry API](https://console.cloud.google.com/apis/library/artifactregistry.googleapis.com) #### Retrieve your Workspace Customer ID Each Google Workspace account has a customer ID, which Veza will need to authenticate. Take note of the customer ID for configuring the integration: 1. From the Admin console Home page, go to **Account settings** > **Profile**. 2. Under *Customer ID*, find your organization's unique ID. Save the customer ID, which you will need when configuring the connection in Veza.\ **Note:** the customer ID should start with a C, for example:`C06k34uds.` For information, see [Find your customer ID - Google Workspace Admin Help](https://support.google.com/a/answer/10070793?hl=en). ## Adding the Integration to Veza 1. In Veza, go to the **Integrations** page 2. Click **Add Integration** 3. Select **Google Cloud Platform** 4. Configure the integration: | Field | Details | | ------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | | Insight Point | The [Insight Point](/4yItIzMvkpAvMVFAamTf/integrations/connectivity/insight-point.md) for discovery | | Name | A friendly name to identify this integration | | Workspace email | Email address of a Workspace admin user that the service account will impersonate via domain-wide delegation (NOT the service account email) | | Customer ID | Workspace Customer ID from Admin console (e.g., `C06k34uds`) | | Credentials.json | WIF configuration file or service account key file | | Limit Google Cloud Services | Optional [extraction limits](/4yItIzMvkpAvMVFAamTf/integrations/configuration/limits.md) | | Identity Mapping Configurations | Configure [Identity Mappings](/4yItIzMvkpAvMVFAamTf/integrations/configuration/custom-identity-mappings.md) | ## Limiting extractions You can restrict which Google Cloud resources Veza discovers by configuring allow and deny lists in the integration settings. These can be set when adding a new integration or by editing an existing one under **Configuration**. The following fields are available: | Field | What it filters | Value format | Example | | -------------------------------- | -------------------------------------------- | -------------------------------------------------------------------------------------- | ------------------------ | | Project Allow/Deny List | GCP projects to include or exclude | Project [ID](https://support.google.com/googleapi/answer/7014113) | `my-project-123` | | Domain Allow/Deny List | Google Workspace users by their email domain | Domain portion of email address | `acme.com` | | Location Allow/Deny List | GCP regions and multi-regions | [Region or multi-region code](https://cloud.google.com/about/locations) | `us-central1`, `US` | | BigQuery Dataset Allow/Deny List | BigQuery datasets | Dataset name only (the portion after the `:` in the full `project:dataset` identifier) | `sales_data`, `*_prod` | | BigQuery Table Allow/Deny List | BigQuery tables within discovered datasets | Table name only (not the full `project.dataset.table` path) | `transactions`, `user_*` | {% hint style="info" %} **BigQuery dataset names:** When Veza evaluates dataset allow and deny lists, it matches against the full dataset identifier (`project-id:dataset-name`). To filter by dataset name across all projects, use a wildcard prefix: `*:sales_data`. To target a specific project, use the full format: `my-project:sales_data`. {% endhint %} {% hint style="success" %} Wildcards (`*`) match any number of characters. For example, `*-prod` matches any resource ending in `-prod`. {% endhint %} See [Limiting Extractions](/4yItIzMvkpAvMVFAamTf/integrations/configuration/limits.md) for general rules about how allow and deny lists interact. ## Troubleshooting ### No organizations returned Veza validates organization access when you add or save the integration. If configuration fails with **"No Google Cloud Organization found"**, or if the integration completes but returns no organization, check for these common causes: 1. **Role bound at the project level instead of the organization level.** Veza requires organization-level access to discover resources across all projects and folders. Ensure the service account role is bound at the organization level, not just at the project level. Check that your organization is selected (not just a project) when creating and binding the custom role. 2. **Missing organization permissions in the custom role.** The custom role must include `resourcemanager.organizations.get` and `resourcemanager.organizations.getIamPolicy`. Without these permissions, the service account cannot discover the organization even if the role is bound at the correct level. Verify both permissions are present in the role definition. 3. **Missing `service_account_impersonation_url` in the WIF credentials file (Workload Identity Federation only).** When using Workload Identity Federation, the downloaded credential configuration file must contain the `service_account_impersonation_url` field. If this field is missing, the federation token exchange may succeed but the service account cannot impersonate correctly, resulting in no organization data. Re-download the configuration file from the Workload Identity Federation provider's **Connected service accounts** panel and confirm the file includes a `service_account_impersonation_url` value similar to: ```json "service_account_impersonation_url": "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/:generateAccessToken" ``` ### Other common issues 1. **Domain-wide delegation not working**: If the Workspace admin user impersonation fails, verify that: * The service account's client ID is correctly entered in the Admin console * All required OAuth scopes are authorized * The Workspace email provided is for an actual admin user, not the service account 2. **API permissions errors**: If discovery fails for specific services, ensure: * The required API is enabled in your project * The service-specific permissions are added to the organization role * The role binding is at the organization level to inherit permissions across all projects --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.veza.com/4yItIzMvkpAvMVFAamTf/integrations/integrations/google.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.