For the complete documentation index, see llms.txt. This page is also available as Markdown.

Monitor GCP resources inside service perimeters

Learn how to grant authorization to Cortex Cloud to scan within your GCP service perimeter.

A service perimeter can provide an additional layer of security for your GCP projects. It serves as a fortified boundary around your Google Cloud resources. While resources inside the perimeter can communicate freely, the perimeter is designed to prevent unauthorized communication to Google Cloud services beyond its confines.

To enable Cortex Cloud to scan assets and resources within your GCP perimeter, you must authorize Cortex Cloud's identities to access the perimeter from within GCP. If you have a perimeter set up in your GCP project and you have not authorized Cortex Cloud's identities to scan the perimeter, you will receive the following error:

Request is prohibited by organization's policy. vpcServiceControlsUniqueIdentifier: {{<GCP-perimeter-ID>}}

Note: Each GCP cloud instance is assigned a scope within GCP. If the scope, whether it be organization, folder, or project, includes any projects with a service perimeter, this procedure must be performed for that cloud instance to authorize Cortex Cloud to scan the resources in the perimeter.

Projects to include in the service perimeter

Enterprise GCP environments using VPC Service Controls must include all GCP projects that communicate with Cortex Cloud in the service perimeter. Depending on your scan mode and enabled security capabilities, this includes more than one project.

Customer-owned projects

Include the following projects that you own:

Project
Description

Your monitored GCP project(s)

Every GCP project that Cortex Cloud is configured to monitor. If your cloud instance scope is an organization or folder, this includes all projects within that scope.

Your outpost project

If you are using Scan with Outpost mode, include the dedicated GCP project where the Cortex Outpost infrastructure is deployed. You can find this project ID in the Cortex Cloud Authorization Details dialog box.

Cortex Cloud-owned projects

Include the following Cortex Cloud-managed GCP projects. The exact project numbers for your tenant are listed in the Authorization Details dialog box in Cortex Cloud (see Obtain Cortex Cloud identity details below).

Project
Description
Scan mode

Cortex Platform project

The Cortex Cloud platform project that hosts the cts-pod service account. This is the primary Cortex Cloud identity that initiates all scanning operations.

Cloud Scan and Outpost Scan

Cortex Outpost project

The Cortex Cloud-managed GCP project that hosts the scanning infrastructure (Compute Engine VMs, Pub/Sub, Cloud Storage).

Cloud Scan mode only

Identify the Cortex Cloud-owned projects. Each Cortex Cloud service account email contains the project it belongs to: the portion between @ and .iam.gserviceaccount.com. For example, a CTS service account of cts-pod@xdr-eu-<tenant-id>.iam.gserviceaccount.com identifies the Cortex Platform project as xdr-eu-<tenant-id>. All platform service accounts share this project, and all scanning service accounts share the Cortex Outpost project, identified the same way from the Cortex Engine service account email.

Service accounts to authorize

The service accounts that require authorization depend on your scan mode and the security capabilities you have enabled. All service account emails for your specific tenant are listed in the Authorization Details dialog box.

Platform service account (all configurations)

Service account
Format
Direction
Purpose

CTS service account

cts-pod@<cortex-platform-project>.iam.gserviceaccount.com

Ingress and Egress

Cortex Cloud platform identity that impersonates the Cortex Engine service account to initiate scanning.

Outpost service accounts (Scan with Outpost mode)

If you are using Scan with Outpost mode, the following additional service accounts in the Outpost project must be authorized:

Service account
Format
Direction
Purpose

Cortex Engine

cortex-engine@<outpost-project>.iam.gserviceaccount.com

Egress

Unified service account for all Outpost operations. The CTS service account impersonates this identity.

Collector

collector-<project-number>@<outpost-project>.iam.gserviceaccount.com

Egress

Collects data from monitored GCP resources.

DSPM Scan Runner

dspm-scan-runner@<outpost-project>.iam.gserviceaccount.com

Egress

Runs Data Security Posture Management (DSPM) scanning instances. Required if DSPM is enabled.

Registry Scan Runner

registry-scan-runner@<outpost-project>.iam.gserviceaccount.com

Egress

Runs container registry scanning instances. Required if Registry Scanning is enabled.

Serverless Scanner

scanner-of-runner@<outpost-project>.iam.gserviceaccount.com

Egress

Runs serverless function scanning instances. Required if Serverless Scanning is enabled. Note: Serverless scanning is uncommon in environments using Google Cloud Run.

Audit log service account (if audit log collection is enabled)

Service account
Format
Direction
Purpose

Audit Logs Service Account

crtx-al-<suffix>@<your-project>.iam.gserviceaccount.com

Ingress

Subscribes to the Pub/Sub subscription to collect GCP audit logs.

Obtain Cortex Cloud identity details

  1. In your Cortex Cloud tenant, select Settings → Data Sources & Integrations.

  2. Hover over the Google Cloud Platform (GCP) row and select View Details.

  3. In the Cloud Instances page, identify the GCP instance with the perimeter, right-click it and select Details.

  4. In the details pane, click the more options icon and select Authorization Details.

  5. The Authorization Details dialog box lists all service account emails and project numbers you need to add as approved identities in GCP.

Add Cortex Cloud authorization values to GCP perimeter

  1. Navigate to VPC Service Controls.

  2. In the list of perimeters, select the perimeter to which you want to grant access to Cortex Cloud.

  3. In the Service perimeter details screen, click Edit.

  4. In the Edit service perimeter screen, select Ingress policy.

  5. In the Ingress rules pane, click Add an ingress rule.

  6. Enter a Title for the ingress rule.

  7. In the From section, under Identities, select Select identities & groups.

  8. Click Add identities. In the Add identities pane, under Search identities, paste Cortex discovery role from Cortex Cloud's Authorization Details dialog box. If there are more authorized values, paste each of them under Search identities. Click Add identities.

  9. In the To section, under Resources, select Select projects.

  10. Click Add projects. In the Add projects pane, select the relevant projects.

  11. Under Operations or IAM roles, select All operations.

  12. Click Next to add an egress rule.

  13. In the Egress rules pane, click Add an egress rule.

  14. Enter a Title for the egress rule.

  15. In the From section, under Identities, select Select identities & groups.

  16. Click Add identities. In the Add identities pane, under Search identities, paste Cortex discovery role from Cortex Cloud's Authorization Details dialog box. If there are more authorized values, paste each of them under Search identities. Click Add identities.

  17. In the To section, under Resources, select Select projects.

  18. Click Add projects. In the Add projects pane, select the relevant projects.

  19. Click Save. Confirm the changes and click Confirm.

Add Cortex-owned projects to the perimeter

To allow Cortex Cloud's scanning infrastructure to communicate with your protected resources, you must also add the Cortex-owned projects to the perimeter as allowed resources:

  1. In the Service perimeter details screen, click Edit.

  2. Under Resources, click Add resources.

  3. Add the Cortex Cloud Platform project and, if applicable, the Cortex Cloud Outpost project using the numeric project numbers from the Authorization Details dialog box.

  4. Click Save and confirm.

The Cortex Cloud authorization values have been added as approved identities in GCP.

Last updated

Was this helpful?