Google Cloud Platform

​

What Oleria discovers

• IAM policy bindings at the organization, folder, project, and resource level.
• Service accounts across the organization or project.
• Google Workspace users and groups, through domain-wide delegation.
• Cloud Storage buckets and who has access to them.
• Secret Manager secrets and their IAM bindings.
• Activity from Cloud Audit Logs, including Secret Manager access events when Data Access audit logs are enabled.
• Risk signals from Security Command Center findings, if you enable it.

​

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. The admin Oleria acts as afterward can have fewer privileges; see the domain-wide delegation step.

​

Integration approaches

• 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.

​

Connect GCP to Oleria

1

Create a connector service account

1. Sign in to the Google Cloud Console. For a project connection, select the target project first. Navigate to IAM & Admin -> Service Accounts.
2. Select Create Service Account. Provide a name such as oleria-connector and select Create and Continue.
3. Skip the optional role grant and user access steps. Select Done.

2

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

1. In the Google Cloud Console, select the project that owns the connector service account from the resource picker.
2. Navigate to APIs & Services -> Enabled APIs & services -> Enable APIs and Services.
3. 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

• Organization
• Project

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. To see secrets across your organization, enable the Secret Manager API on each project that has billing enabled (Secret Manager is a billable API), using the procedure below.

Enable Secret Manager on every billed project in your organization

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 procedure:

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 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

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

3

Grant IAM roles to the connector service account

• Organization
• Project

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

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

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

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 organization or 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.

4

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.

• Organization
• Project

1. Enable the Security Command Center API (securitycenter.googleapis.com) in the host project.
2. Grant the connector service account roles/securitycenter.findingsViewer at the organization level.
3. 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.

1. Enable the Security Command Center API (securitycenter.googleapis.com) in the host project.
2. Grant the connector service account roles/securitycenter.findingsViewer at the project level.
3. 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.

5

Generate a service account key

1. In IAM & Admin -> Service Accounts, select the service account you created in the first step.
2. Navigate to the Keys tab and select Add Key -> Create new key.
3. 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.

If key creation is blocked, your organization enforces the iam.disableServiceAccountKeyCreation organization policy. Google Cloud enforces this policy by default on newer organizations. An Organization Policy Administrator needs to allow key creation for the project that owns the connector service account before you can create the JSON key.

6

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.

1. Sign 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.
2. Select Add new.
3. 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

4. Select Authorize.

Oleria acts as the admin you enter as Google Workspace Admin Email in the final step. That admin doesn’t need to be the Super Admin who sets up domain-wide delegation. Any of these works:

• Super Admin - covers discovery and group remediation.
• A custom admin role with the Admin API privileges Users -> Read and Groups -> Read - covers discovery.
• The same custom role plus the Groups Admin role (or the Groups -> Update privilege) - covers discovery and group remediation.

Use the least-privileged option that covers what you plan to do.

7

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.

• Organization
• Project

Option A: Using the Google Cloud Console

1. In the Cloud Console, confirm your Organization is selected in the resource picker at the top of the page.
2. 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.
3. 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.
4. On the Log Router Sinks page, confirm the resource scope shows your Organization, then select Create Sink at the top of the page.
5. 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.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:

logName=~"cloudaudit.googleapis.com"

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.

6. After the sink is created, open it from the Log Router Sinks list and copy the Writer Identity service account email (for example, serviceAccount:p123456789-xxxxxx@gcp-sa-logging.iam.gserviceaccount.com). You will use this address in the next step.
7. 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

1. Create a Cloud Storage bucket to receive audit logs:

gcloud storage buckets create gs://YOUR_AUDIT_BUCKET --project=YOUR_PROJECT_ID

2. 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

3. 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)')

gcloud storage buckets add-iam-policy-binding gs://YOUR_AUDIT_BUCKET \
  --member="${SINK_SA}" --role="roles/storage.objectCreator"

4. Grant the connector service account read access to the bucket:

gcloud storage buckets add-iam-policy-binding gs://YOUR_AUDIT_BUCKET \
  --member="serviceAccount:oleria-connector@YOUR_PROJECT_ID.iam.gserviceaccount.com" \
  --role="roles/storage.objectViewer"

Option A: Using the Google Cloud Console

1. In the Cloud Console, confirm the target Project is selected in the resource picker at the top of the page.
2. 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.
3. 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.
4. On the Log Router Sinks page, confirm the resource scope shows your target Project, then select Create Sink at the top of the page.
5. 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.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.

6. After the sink is created, open it from the Log Router Sinks list and copy the Writer Identity service account email (for example, serviceAccount:p123456789-xxxxxx@gcp-sa-logging.iam.gserviceaccount.com). You will use this address in the next step.
7. 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

1. Create a Cloud Storage bucket to receive audit logs:

gcloud storage buckets create gs://YOUR_AUDIT_BUCKET --project=YOUR_PROJECT_ID

2. 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

3. 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)')

gcloud storage buckets add-iam-policy-binding gs://YOUR_AUDIT_BUCKET \
  --member="${SINK_SA}" --role="roles/storage.objectCreator"

4. Grant the connector service account read access to the bucket:

gcloud storage buckets add-iam-policy-binding gs://YOUR_AUDIT_BUCKET \
  --member="serviceAccount:oleria-connector@YOUR_PROJECT_ID.iam.gserviceaccount.com" \
  --role="roles/storage.objectViewer"

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.

8

Connect GCP to Oleria

• Organization
• Project

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

• Organization ID - your numeric GCP Organization ID (for example, 123456789012). Found under IAM & Admin -> Settings in the Cloud Console.
• Google Workspace Admin Email - email address of the Google Workspace admin Oleria acts as to read users and groups, and to run group remediations
• Service Account Credentials - paste the full contents of the JSON key file downloaded above

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

• Project ID - your GCP Project ID (for example, my-project). Found in the Cloud Console project selector at the top of the page.
• Google Workspace Admin Email - email address of the Google Workspace admin Oleria acts as to read users and groups, and to run group remediations
• Service Account Credentials - paste the full contents of the JSON key file downloaded above

​

Verify the integration

​

Enable remediation actions (optional)

• 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 revoke an IAM binding on a folder, grant roles/resourcemanager.folderIamAdmin on the folder or the organization.
• To revoke an IAM binding on a service account, grant roles/iam.serviceAccountAdmin on the project that owns the service account.
• To revoke an IAM binding on a Cloud Storage bucket, grant roles/storage.admin on the bucket or its project.
• To remove a member from a Cloud Identity group, make sure the admin you entered as Google Workspace Admin Email is a Super Admin or also has the Groups Admin role (or the Groups -> Update Admin API privilege) in the Google Admin console, and add the https://www.googleapis.com/auth/cloud-identity.groups scope to the domain-wide delegation entry you created earlier. Group management is controlled by Google Workspace admin roles, not GCP IAM roles.
• To disable a service account, grant roles/iam.serviceAccountAdmin on the project that owns the service account.

​

Contact us