Google Cloud Platform

Oleria provides identity security and access management teams with visibility and intelligence into who has access to what, where they got that access, how they use it, and whether they should even have it. As part of that promise, we deeply integrate your Google Cloud Platform environment into the Oleria platform. This document provides step-by-step guidance for integrating GCP - at either the organization level or project level - with your Oleria workspace.

Prerequisites

GCP Organization Admin or Project Owner role to grant IAM roles to the connector service account
Google Workspace Super Admin role to configure domain-wide delegation

Use a service account (and not an employee account) with the suggested privileges for the integration to ensure continuity.

Integration Approaches

Oleria supports two integration scopes. Follow the one most appropriate for your organization.

Organization (Recommended) - Oleria sees all projects, folders, and resources across your entire GCP org, including org-level IAM policies and cross-project bindings. Recommended for full visibility.
Project - Oleria is scoped to IAM bindings, resources, and storage within a single project only. Use this if you don’t have org-level access or only want to connect a specific project.

Integrate GCP Organization

Create a Connector Service Account

Log in to the Google Cloud Console and navigate to IAM & Admin → Service Accounts.
Select Create Service Account. Provide a name such as oleria-connector and select Create and Continue.
Skip the optional role grant and user access steps. Select Done.

Enable Required GCP APIs

The connector calls a number of Google Cloud APIs. Each one must be enabled in the host project of the connector service account; if any are disabled, authentication or sync will fail.Option A: Using the Google Cloud Console

In the Google Cloud Console, select the project that owns the connector service account from the resource picker.
Navigate to APIs & Services → Enabled APIs & services → Enable APIs and Services.
Search for and enable each of the following:
- Cloud Resource Manager API
- Identity and Access Management (IAM) API
- Cloud Asset API
- Cloud Identity API
- Admin SDK API
- Cloud Storage API
- Cloud Logging API
- Secret Manager API

Option B: Using the gcloud CLI

gcloud services enable \
  cloudresourcemanager.googleapis.com \
  iam.googleapis.com \
  cloudasset.googleapis.com \
  cloudidentity.googleapis.com \
  admin.googleapis.com \
  storage.googleapis.com \
  logging.googleapis.com \
  secretmanager.googleapis.com \
  --project=YOUR_PROJECT_ID

YOUR_PROJECT_ID is the project that owns the connector service account. For Cloud Resource Manager, IAM, Cloud Asset, Cloud Identity, Admin SDK, Cloud Storage, and Cloud Logging, enabling the API on this single host project is sufficient - the connector calls these APIs on behalf of resources across the whole organization. Secret Manager is the exception; see below.

Secret Manager is enabled per-project, not org-wide. Google checks the project that owns each secret, not the connector’s host project - so this API needs a separate step, and only on projects that have billing enabled (Secret Manager is a billable API).Who runs this: you, using your own Google account - not the connector service account. This is a one-time setup task and grants nothing to the connector itself (that happens in the next Step).Roles you need for this step:

Role	For	Granted where
`roles/cloudasset.viewer`	listing projects in the org	organization level
`roles/serviceusage.serviceUsageAdmin`	enabling the API	organization level
`roles/billing.viewer`	listing billed projects	on each billing account

Grant yourself the first two if you don’t already have them - Organization Admin from Prerequisites does not include any of these three roles:

gcloud organizations add-iam-policy-binding YOUR_ORG_ID \
  --member="user:YOUR_EMAIL" --role="roles/cloudasset.viewer"

gcloud organizations add-iam-policy-binding YOUR_ORG_ID \
  --member="user:YOUR_EMAIL" --role="roles/serviceusage.serviceUsageAdmin"

The billing role must be granted by whoever already administers the billing account (find YOUR_BILLING_ACCOUNT_ID under Billing → Account Management):

gcloud billing accounts add-iam-policy-binding YOUR_BILLING_ACCOUNT_ID \
  --member="user:YOUR_EMAIL" --role="roles/billing.viewer"

Why the script below builds two lists instead of one: a billing account isn’t owned by an organization - the same billing account can pay for projects in other orgs too. So “every project my billing account pays for” and “every project in my org” are two different questions with two different answers. The script asks both and keeps only the overlap, so it never touches a project outside your org.

ORG_PROJECTS=$(gcloud asset search-all-resources \
  --scope="organizations/YOUR_ORG_ID" \
  --asset-types="cloudresourcemanager.googleapis.com/Project" \
  --format="value(name)" \
| sed 's#.*/##' | sort -u)

BILLED_PROJECTS=$(for acct in $(gcloud billing accounts list --format="value(name)"); do
  gcloud billing projects list --billing-account="$acct" \
    --filter="billingEnabled=true" \
    --format="value(projectId)"
done | sort -u)

if [ -z "$ORG_PROJECTS" ] || [ -z "$BILLED_PROJECTS" ]; then
  echo "No projects resolved - check that both commands above succeeded." >&2
fi

TARGETS=$(comm -12 <(echo "$ORG_PROJECTS") <(echo "$BILLED_PROJECTS"))
echo "$TARGETS" | wc -l
echo "$TARGETS"

Review the $TARGETS list above before continuing - enabling a service is a state change with no bulk undo. Once it looks right:

echo "$TARGETS" | while read -r p; do
  [ -n "$p" ] || continue
  if err=$(gcloud services enable secretmanager.googleapis.com --project="$p" 2>&1); then
    echo "$p: ENABLED"
  else
    echo "$p: FAILED - $(echo "$err" | head -1)"
  fi
done

A project left off this list simply isn’t checked for secrets - nothing else about its integration is affected. You can run this against a subset of $TARGETS if you only want secret visibility in some projects.

Placeholder	Replace with
`YOUR_ORG_ID`	numeric org ID, under IAM & Admin → Settings
`YOUR_EMAIL`	your own Google account, not the connector’s
`YOUR_BILLING_ACCOUNT_ID`	under Billing → Account Management

Grant IAM Roles at the Organization Level

In the Google Cloud Console, click the project selector at the top of the page and select your Organization from the resource picker.
Navigate to IAM & Admin → IAM and select Grant Access.
Enter the connector service account email and assign the following roles:

roles/iam.securityReviewer
roles/cloudasset.viewer
roles/resourcemanager.organizationViewer
roles/resourcemanager.folderViewer
roles/storage.objectViewer
roles/logging.viewer
roles/secretmanager.viewer

roles/cloudasset.viewer lets the connector use Cloud Asset Inventory to scan IAM policy bindings and service account inventory across the organization in bulk, rather than resource by resource. Sync fails without it. roles/logging.viewer is required for activity sync via Cloud Audit Logs. roles/secretmanager.viewer grants 11 permissions in total; of those, Oleria’s connector relies on three - secretmanager.secrets.list, secretmanager.secrets.getIamPolicy, and secretmanager.versions.get. Oleria never reads secret values, so roles/secretmanager.secretAccessor (which grants secretmanager.versions.access) is intentionally NOT required.

Enable Security Command Center for Risk Monitoring (Optional)

Oleria’s GCP risk signals come entirely from Security Command Center (SCC) findings.

Skipping this step doesn’t break setup - the connection still completes and syncs your IAM data normally - but no GCP risks will appear in Risk Monitoring until all three of the following are done.

Enable the Security Command Center API (securitycenter.googleapis.com) in the host project.
Grant the connector service account roles/securitycenter.findingsViewer at the organization level.
Confirm SCC itself is activated for your organization. This is separate from enabling the API: go to Security Command Center in the Cloud Console and select your organization. If a findings dashboard loads, SCC is active. If you see an activation prompt instead, an Organization Administrator or Security Center Admin needs to activate a tier (Standard is free) before Oleria can surface findings.

Generate a Service Account Key

In IAM & Admin → Service Accounts, select the service account you created in the first step.
Navigate to the Keys tab and select Add Key → Create new key.
Select JSON format and select Create. The key file will be downloaded to your machine. Keep this file secure - you will provide it to Oleria in the final step.

Configure Domain-Wide Delegation in Google Workspace

Domain-wide delegation allows the connector service account to enumerate Google Workspace users and groups on behalf of a delegated admin.

Log in to the Google Workspace Admin Console and navigate to Security → Access and data control → API controls. Under Domain-wide delegation, select Manage Domain Wide Delegation.
Select Add new.
Provide the Client ID of the service account (found under IAM & Admin → Service Accounts → select the SA → Details tab → Unique ID) and add the following OAuth scopes:

https://www.googleapis.com/auth/admin.directory.user.readonly
https://www.googleapis.com/auth/cloud-identity.groups.readonly

Domain-wide delegation dialog with Client ID and OAuth scopes fields completed

Select Authorize.

The Google Workspace admin email provided as the Workspace Delegate Email in the final step must have at least read access to user and group directories.

Set Up Audit Log Export for Activity Sync

This step enables Oleria to ingest Cloud Audit Logs for user activity insights.

Choose a globally unique name for your audit log bucket - you’ll use it as YOUR_AUDIT_BUCKET throughout this step.

Option A: Using the Google Cloud Console

In the Cloud Console, confirm your Organization is selected in the resource picker at the top of the page.
Navigate to Cloud Storage → Buckets and select Create. Provide a globally unique bucket name (this will be your YOUR_AUDIT_BUCKET), choose a location, and accept the defaults for the remaining settings. Select Create.
Navigate to Logging → Log Router. The fastest way is to type log router in the GCP search bar at the top of the page and select Log Router (listed as Product page - Logging) from the results.
On the Log Router Sinks page, confirm the resource scope shows your Organization, then select Create Sink at the top of the page.
The Create logs routing sink wizard opens with four steps. Complete them as follows:

Sink details: Enter audit-log-sink as the Sink name. Optionally add a description. Select Next.Sink destination: From the Select sink service dropdown, choose Cloud Storage bucket and select your bucket. GCP will automatically switch the service type to Other resource and populate the Sink destination field with storage.googleapis.com/YOUR_AUDIT_BUCKET - this is expected behavior at the organization level. Select Next.

Sink destination step showing Other resource selected with storage.googleapis.com URI

Choose logs to include in sink: Select Include logs ingested by this organization and all child resources. This ensures audit logs from all projects and folders across your organization are captured. Then, in the Build inclusion filter field, enter the following and select Next:

Choose logs to include showing Include logs ingested by this organization and all child resources selected

logName=~"cloudaudit.googleapis.com"

Build inclusion filter field with logName cloudaudit.googleapis.com filter entered

GCP may show a caution that a large number of log entries could be routed. This is expected - the inclusion filter above limits export to audit logs only.

Choose logs to filter out of sink (optional): No exclusion filters are needed. Select Create Sink.

After the sink is created, open it from the Log Router Sinks list and copy the Writer Identity service account email (e.g. serviceAccount:p123456789-xxxxxx@gcp-sa-logging.iam.gserviceaccount.com). You will use this address in the next step.
Navigate to Cloud Storage → Buckets, select your audit log bucket, open the Permissions tab, and select Grant Access. Add the following two principals, then select Save:
- Sink writer: In the New principals field, paste the Writer Identity email you copied. In the Role dropdown, search for and select Storage Object Creator.
- Oleria connector: In the New principals field, enter oleria-connector@YOUR_PROJECT_ID.iam.gserviceaccount.com. In the Role dropdown, search for and select Storage Object Viewer.

Option B: Using the gcloud CLI

Create a GCS bucket to receive audit logs:

gsutil mb -p YOUR_PROJECT_ID gs://YOUR_AUDIT_BUCKET

Create a Log Sink that exports organization-wide audit logs to the bucket:

gcloud logging sinks create audit-log-sink \
  storage.googleapis.com/YOUR_AUDIT_BUCKET \
  --log-filter='logName=~"cloudaudit.googleapis.com"' \
  --include-children \
  --organization=YOUR_ORG_ID

Grant the sink’s writer service account write access to the bucket:

SINK_SA=$(gcloud logging sinks describe audit-log-sink \
  --organization=YOUR_ORG_ID --format='value(writerIdentity)')

gsutil iam ch ${SINK_SA}:objectCreator gs://YOUR_AUDIT_BUCKET

Grant the connector service account read access to the bucket:

gsutil iam ch serviceAccount:oleria-connector@YOUR_PROJECT_ID.iam.gserviceaccount.com:objectViewer \
  gs://YOUR_AUDIT_BUCKET

Oleria automatically discovers the audit log bucket by inspecting Log Sinks - no additional configuration is needed in the Oleria workspace.

Optional: enable Data Access audit logs for Secret Manager eventsTo capture secret metadata and access events, enable Admin Read and/or Data Read audit logs for the Secret Manager API. In the Cloud Console, go to IAM & Admin → Audit Logs, find Secret Manager API, and check the categories you want. The audit log sink configured above picks up these events automatically once they are enabled.

Category	Examples	Requires enablement
Admin Activity	`CreateSecret`, `UpdateSecret`, `DeleteSecret`, `AddSecretVersion`, `EnableSecretVersion`, `DisableSecretVersion`	No - always on
Admin Read	`GetSecret`, `GetSecretVersion`, `ListSecrets`, `ListSecretVersions`, `GetIamPolicy` (on a secret)	Yes - enable Admin Read
Data Read	`AccessSecretVersion`	Yes - enable Data Read

Without Data Access logging, Oleria surfaces Admin Activity events only. Data Read events (who accessed a secret value, and when) are the primary signal for identifying unused or over-permissioned secrets.

Connect GCP Organization to Oleria

Log in to your Oleria workspace, select Integrations → select Google Cloud Platform. A side panel opens. Select Organization (Recommended) from the Connector Scope dropdown.
Provide the following and select Authenticate:

Organization ID - your numeric GCP Organization ID (e.g. 123456789012). Found under IAM & Admin → Settings in the Cloud Console.
Workspace Delegate Email - email address of the Google Workspace admin whose permissions will be used to enumerate users and groups
Service Account Credentials - paste the full contents of the JSON key file downloaded above

Find the newly integrated GCP Organization in your Oleria workspace connected integrations.

Integrate GCP Project

Create a Connector Service Account

Log in to the Google Cloud Console, select the target project, and navigate to IAM & Admin → Service Accounts.
Select Create Service Account. Provide a name such as oleria-connector and select Create and Continue.
Skip the optional role grant and user access steps. Select Done.

Enable Required GCP APIs

In the Google Cloud Console, select the project that owns the connector service account from the resource picker.
Navigate to APIs & Services → Enabled APIs & services → Enable APIs and Services.
Search for and enable each of the following:
- Cloud Resource Manager API
- Identity and Access Management (IAM) API
- Cloud Asset API
- Cloud Identity API
- Admin SDK API
- Cloud Storage API
- Cloud Logging API
- Secret Manager API

Option B: Using the gcloud CLI

gcloud services enable \
  cloudresourcemanager.googleapis.com \
  iam.googleapis.com \
  cloudasset.googleapis.com \
  cloudidentity.googleapis.com \
  admin.googleapis.com \
  storage.googleapis.com \
  logging.googleapis.com \
  secretmanager.googleapis.com \
  --project=YOUR_PROJECT_ID

YOUR_PROJECT_ID is the project that owns the connector service account, which is also the target project for this integration.

Grant IAM Roles at the Project Level

In the Google Cloud Console, navigate to IAM & Admin → IAM for the target project and select Grant Access.
Enter the connector service account email and assign the following roles:

roles/iam.securityReviewer
roles/cloudasset.viewer
roles/storage.objectViewer
roles/logging.viewer
roles/secretmanager.viewer

roles/cloudasset.viewer lets the connector use Cloud Asset Inventory to scan IAM policy bindings and service account inventory across the project in bulk, rather than resource by resource. Sync fails without it. roles/logging.viewer is required for activity sync via Cloud Audit Logs. roles/secretmanager.viewer grants 11 permissions in total; of those, Oleria’s connector relies on three - secretmanager.secrets.list, secretmanager.secrets.getIamPolicy, and secretmanager.versions.get. Oleria never reads secret values, so roles/secretmanager.secretAccessor (which grants secretmanager.versions.access) is intentionally NOT required.

Enable Security Command Center for Risk Monitoring (Optional)

Oleria’s GCP risk signals come entirely from Security Command Center (SCC) findings.

Skipping this step doesn’t break setup - the connection still completes and syncs your IAM data normally - but no GCP risks will appear in Risk Monitoring until all three of the following are done.

Enable the Security Command Center API (securitycenter.googleapis.com) in the host project.
Grant the connector service account roles/securitycenter.findingsViewer at the project level.
Confirm SCC itself is activated for this project. This is separate from enabling the API: go to Security Command Center in the Cloud Console and select the project. If a findings dashboard loads, SCC is active. If you see an activation prompt instead, a Security Center Admin needs to activate a tier (Standard is free) for the project before Oleria can surface findings.

Generate a Service Account Key

In IAM & Admin → Service Accounts, select the service account you created in the first step.
Navigate to the Keys tab and select Add Key → Create new key.
Select JSON format and select Create. The key file will be downloaded to your machine. Keep this file secure - you will provide it to Oleria in the final step.

Configure Domain-Wide Delegation in Google Workspace

Domain-wide delegation allows the connector service account to enumerate Google Workspace users and groups on behalf of a delegated admin.

Log in to the Google Workspace Admin Console and navigate to Security → Access and data control → API controls. Under Domain-wide delegation, select Manage Domain Wide Delegation.
Select Add new.
Provide the Client ID of the service account (found under IAM & Admin → Service Accounts → select the SA → Details tab → Unique ID) and add the following OAuth scopes:

https://www.googleapis.com/auth/admin.directory.user.readonly
https://www.googleapis.com/auth/cloud-identity.groups.readonly

Select Authorize.

The Google Workspace admin email provided as the Workspace Delegate Email in the final step must have at least read access to user and group directories.

Set Up Audit Log Export for Activity Sync

This step enables Oleria to ingest Cloud Audit Logs for user activity insights.

Choose a globally unique name for your audit log bucket - you’ll use it as YOUR_AUDIT_BUCKET throughout this step.

Option A: Using the Google Cloud Console

In the Cloud Console, confirm the target Project is selected in the resource picker at the top of the page.
Navigate to Cloud Storage → Buckets and select Create. Provide a globally unique bucket name (this will be your YOUR_AUDIT_BUCKET), choose a location, and accept the defaults for the remaining settings. Select Create.
Navigate to Logging → Log Router. The fastest way is to type log router in the GCP search bar at the top of the page and select Log Router (listed as Product page - Logging) from the results.
On the Log Router Sinks page, confirm the resource scope shows your target Project, then select Create Sink at the top of the page.
The Create logs routing sink wizard opens with four steps. Complete them as follows:

Sink details: Enter audit-log-sink as the Sink name. Optionally add a description. Select Next.Sink destination: From the Select sink service dropdown, choose Cloud Storage bucket. Select your bucket from the browser, or type the destination directly as storage.googleapis.com/YOUR_AUDIT_BUCKET. Select Next.

Full sink creation wizard at project level showing Cloud Storage bucket destination

Choose logs to include in sink: In the Build inclusion filter field, enter the following and select Next:

logName=~"cloudaudit.googleapis.com"

Choose logs to filter out of sink (optional): No exclusion filters are needed. Select Create Sink.

After the sink is created, open it from the Log Router Sinks list and copy the Writer Identity service account email (e.g. serviceAccount:p123456789-xxxxxx@gcp-sa-logging.iam.gserviceaccount.com). You will use this address in the next step.
Navigate to Cloud Storage → Buckets, select your audit log bucket, open the Permissions tab, and select Grant Access. Add the following two principals, then select Save:
- Sink writer: In the New principals field, paste the Writer Identity email you copied. In the Role dropdown, search for and select Storage Object Creator.
- Oleria connector: In the New principals field, enter oleria-connector@YOUR_PROJECT_ID.iam.gserviceaccount.com. In the Role dropdown, search for and select Storage Object Viewer.

Option B: Using the gcloud CLI

Create a GCS bucket to receive audit logs:

gsutil mb -p YOUR_PROJECT_ID gs://YOUR_AUDIT_BUCKET

Create a Log Sink that exports project-level audit logs to the bucket:

gcloud logging sinks create audit-log-sink \
  storage.googleapis.com/YOUR_AUDIT_BUCKET \
  --log-filter='logName=~"cloudaudit.googleapis.com"' \
  --project=YOUR_PROJECT_ID

Grant the sink’s writer service account write access to the bucket:

SINK_SA=$(gcloud logging sinks describe audit-log-sink \
  --project=YOUR_PROJECT_ID --format='value(writerIdentity)')

gsutil iam ch ${SINK_SA}:objectCreator gs://YOUR_AUDIT_BUCKET

Grant the connector service account read access to the bucket:

gsutil iam ch serviceAccount:oleria-connector@YOUR_PROJECT_ID.iam.gserviceaccount.com:objectViewer \
  gs://YOUR_AUDIT_BUCKET

Oleria automatically discovers the audit log bucket by inspecting Log Sinks - no additional configuration is needed in the Oleria workspace.

Category	Examples	Requires enablement
Admin Activity	`CreateSecret`, `UpdateSecret`, `DeleteSecret`, `AddSecretVersion`, `EnableSecretVersion`, `DisableSecretVersion`	No - always on
Admin Read	`GetSecret`, `GetSecretVersion`, `ListSecrets`, `ListSecretVersions`, `GetIamPolicy` (on a secret)	Yes - enable Admin Read
Data Read	`AccessSecretVersion`	Yes - enable Data Read

Connect GCP Project to Oleria

Log in to your Oleria workspace, select Integrations → select Google Cloud Platform. A side panel opens. Select Project from the Connector Scope dropdown.
Provide the following and select Authenticate:

Project ID - your GCP Project ID (e.g. my-project). Found in the Cloud Console project selector at the top of the page.
Workspace Delegate Email - email address of the Google Workspace admin whose permissions will be used to enumerate users and groups
Service Account Credentials - paste the full contents of the JSON key file downloaded above

Find the newly integrated GCP Project in your Oleria workspace connected integrations.

Enable Remediations (Optional)

Remediations allow Oleria to take automated or one-click corrective actions - such as revoking an IAM binding, removing a group member, or disabling a service account - directly from the Oleria workspace. To allow Oleria to take remediation actions in your GCP environment, grant the connector service account the following additional roles:

To revoke an IAM binding at the project level, grant roles/resourcemanager.projectIamAdmin on the project.
To revoke an IAM binding at the organization level, grant roles/resourcemanager.organizationIamAdmin on the organization.
To remove a member from a Cloud Identity group, grant roles/cloudidentity.groups.editor.
To disable a service account, grant roles/iam.serviceAccountAdmin on the project that owns the service account.

Secret Manager secrets are discovery-only in this integration. The revoke IAM binding remediations above apply to project, folder, organization, GCS bucket, and service account bindings, but not to Secret Manager secret bindings.

Contact us

For questions about this integration, contact us at support@oleria.com.

Overview

Integration Studio

Applications

Ticketing

Messaging

Prerequisites

Integration Approaches

Integrate GCP Organization

Integrate GCP Project

Enable Remediations (Optional)

Contact us

​Prerequisites

​Integration Approaches

​Integrate GCP Organization

​Integrate GCP Project

​Enable Remediations (Optional)

​Contact us

Prerequisites

Integration Approaches

Integrate GCP Organization

Integrate GCP Project

Enable Remediations (Optional)

Contact us