Configure CDR and CIEM for GCP

• Pub Sub
• Service Account

To configure CDR and CIEM, set up log ingestion.

Prerequisites

• You must have an GCP Project or Organization already connected to Sysdig.
• Access to a User with the permissions required to install.

Set Up Log Ingestion

1. Log in to Sysdig Secure, select Integrations > Cloud Accounts > GCP.
2. Select an account that is part of the organization you would like to add features to or the individual account you onboarded. On the right panel, you will see a list of features.
3. Click Setup beside a feature to open the wizard.
4. Verify the details of your organization and the project where the features will be added.
5. Select the project where the Pub Sub will be deployed to forward logs to Sysdig (to set up log ingestion). We recommend that you use your primary region.
6. Generate and apply the Terraform code:
7. Create a log_ingestion.tf file in the folder that contains your main.tf.
8. Copy the snippet provided into the log_ingestion.tf file.
9. Run the command: terraform init && terraform apply.

Customize Log Ingestion

When you configure a Log Ingestion component, both Identity and Access Management and Cloud Detection and Response are enabled by default.

To disable either of these features, follow the instructions below.

1. Retrieve the log_ingestion.tf Terraform snippet as described above.

2. Before running terraform init && terraform apply, comment out the relevant stanza from the snippet.

   We recommend commenting out the stanza instead of removing it entirely, in case you want to enable the feature in the future.

   1. To disable Identity and Access Management, comment out:

      resource "sysdig_secure_cloud_auth_account_feature" "identity_entitlement" {
          account_id = module.onboarding.sysdig_secure_account_id
          type       = "FEATURE_SECURE_IDENTITY_ENTITLEMENT"
          enabled    = true
          components = [module.event-hub.event_hub_component_id]
          depends_on = [module.event-hub, sysdig_secure_cloud_auth_account_feature.config_posture]
      }
      

   2. To disable Cloud Detection and Response, comment out:

      resource "sysdig_secure_cloud_auth_account_feature" "threat_detection" {
          account_id = module.onboarding.sysdig_secure_account_id
          type       = "FEATURE_SECURE_THREAT_DETECTION"
          enabled    = true
          components = [module.event-hub.event_hub_component_id]
          depends_on = [module.event-hub]
      }
      

3. Run terraform init && terraform apply

Customize Log Ingestion after Installation

Disabling or re-enabling features after applying the Terraform is possible, simply comment or uncomment the feature stanza as described above, and re-run terraform apply.

Advanced Customization

Advanced customization is available via variables in the Terraform module. Modifying these values can cause installation and/or feature operation to fail, so contact your Sysdig representative before modifying these values.

Tune the Cloud Logs Volume

When you set up CDR, Sysdig creates a log sink to access logs through Pub/Sub. As a high volume of logs are costly to process, you may wish to tune the number of logs sent to the log sink:

• To tune which logs are generated, see Tune Log Generation.

• To set up inclusion or exclusion filters, see Tune the Log Sink Filter.

Tune Audit Log Generation

CDR enables Data Access audit logs for every service on every connected project by default:

[
  {
    service = "allServices"
    log_config = [
      { log_type = "ADMIN_READ" },
      { log_type = "DATA_READ" },
      { log_type = "DATA_WRITE" }
    ]
  }
]

You can customize this to change the enabled log types or specify the single services. For a the list of services providing audit logs, see the Google Cloud documentation.

To customize this, specify the audit_log_config variable for the threat-detection module:

module "threat-detection" {
  ...
  audit_log_config = [
    {
      service = "storage.googleapis.com"
      log_config = [
        { log_type = "DATA_WRITE" }
      ]
    },
    {
      service = "cloudsql.googleapis.com"
      log_config = [
        { log_type = "ADMIN_READ" },
        { log_type = "DATA_READ" },
        { log_type = "DATA_WRITE" }
      ]
    }
  ]
}

Tune the Log Sink Filter

By default, the log sink filter is configured to only pick up Audit logs: protoPayload.@type = \"type.googleapis.com/google.cloud.audit.AuditLog\". You can add exclusion filters to narrow the scope further.

You can customize the filter by specifying the ingestion_sink_filter in the threat-detection module.

This example snippet excludes get and list methods for Data Access audit logs:

module "threat-detection" {
  ...
 ingestion_sink_filter = "protoPayload.@type = \"type.googleapis.com/google.cloud.audit.AuditLog\" (protoPayload.methodName !~ \"\\.(get|list)$\" OR logName !~ \"%2Fdata_access$\")"
}

Alternatively you can specify exclude filters with the exclude_logs_filter variable in the same module.

This example excludes:

• gets and lists on kubernetes
• gets and lists on Google Cloud Storage (GCS)

module "threat-detection" {
  ...
  exclude_logs_filter = [
    {
      name        = "k8s_get_list"
      description = "Exclude get and list methods on kubernetes"
      filter      = "protoPayload.serviceName=\"k8s.io\" AND protoPayload.methodName =~ (\"\\.get$\" OR \"\\.list$\")"
    },
    {
      name        = "storage_objects_get_list"
      description = "Exclude get and list methods on GCS objects"
      filter      = "protoPayload.methodName = (\"google.storage.objects.get\" OR \"google.storage.objects.list\" OR \"storage.objects.get\" OR \"storage.objects.list\")"
    }
  ]
}

The following example for the organization threat detection module excludes:

• specific project logs
• specific folder logs

module "threat-detection" {
  ...
  exclude_logs_filter = [
    {
      name        = "exclude_project_test"
      description = "Exclude GCP Test Project logs"
      filter      = "source(projects/my-test-project-id)"
    },
    {
      name        = "exclude_folder_sandbox"
      description = "Exclude GCP Sandbox Folder logs"
      filter      = "source(folders/my-sandbox-folder-id)"
    },
  ]
}

For the full syntax of the filtering options, see Google Cloud Logging query language page.

Configure Domain-Wide Delegation

What is Domain-Wide-Delegation?

In GCP, domain-wide delegation (DWD) refers to a feature in Google Workspace (formerly G Suite). It allows a Google Workspace super admin to delegate authority to a service account to access user data on behalf of users within the domain. Once set up, Sysdig uses a service account that can impersonate users by specifying the subject parameter in its authentication request, setting it to the email address of the Google Workspace user it wishes to impersonate.

Review domain-wide delegation permissions before you configure DWD.

Domain-wide delegation entails:

• Service Account Access: It allows a service account to impersonate a Google Workspace user and gain access to the Google data the user has access to, assuming they have provisioned the necessary Authorization scopes to the Service Account.
• No User Consent Required: With DWD, individual user consent is not required. Once the super admin sets up the delegation, the service account can access the specified data of any user in the domain without additional authorization prompts.
• OAuth 2.0 Scopes: When setting up DWD, the super admin specifies which OAuth 2.0 scopes the service account is granted. For instance, they might grant access to the Directory API to allow the service account to read group member data.
• Security: Because DWD grants broad access, it’s essential to handle it with care. Ensure that you keep the service account’s private key (used for authentication) secure.

Where is Domain-Wide Delegation Used?

Sysdig’s CIEM analysis requires DWD to provide:

• User and Group Insights derived from Google Workspace and Cloud Identity If DWD is enabled, then Unused Permission Criticality, Excessive Permissions, and Members are displayed on the Identity and Access Groups page.
• Enhanced Monitoring and Reporting for MFA usage, user logins, admin console changes, and third-party application access
• Asset management to gain insights into Roles, Service Accounts, and their associated keys

The onboarding wizard prompts you to perform domain-wide delegation. If you skip this step, you will be prompted again from the Identity and Access (CIEM) page of the Sysdig Secure UI.

Enable Domain-Wide Delegation in GCP

Authorize Service Account Scopes

1. Log in to the Google Admin Console with Super Administrator privileges and select Security > Access and data control > API controls.

2. Click Manage Domain Wide Delegation.

3. Click Add New.

4. Switch to the Google Cloud Console to collect your service account’s OAuth 2 Client ID:

• Navigate to the Project specified during the initial onboarding step.

• Select Service Account and search for the newly created Sysdig service account with the format: sysdig-secure-a1b2@your-project-id.iam.gserviceaccount.com.

• Click the Service Account link to display the OAuth 2 Client ID and copy it.

  

5. Return to the Google Admin Console from Step 3. (Security > Access and data control > API controls > Manage Domain Wide Delegation > Add New ).

   

   In the panel, enter:

• Client ID: Paste the OAuth 2 Client ID you copied.

• OAuth Scopes: Add the OAuth scopes below in a comma-delimited list.

  https://www.googleapis.com/auth/cloud-identity.groups.readonly,
  https://www.googleapis.com/auth/admin.directory.user.readonly,
  https://www.googleapis.com/auth/admin.directory.group.readonly,
  https://www.googleapis.com/auth/admin.directory.group.member.readonly,
  https://www.googleapis.com/auth/cloud-platform.read-only,
  https://www.googleapis.com/auth/logging.read,
  https://www.googleapis.com/auth/admin.reports.audit.readonly,
  https://www.googleapis.com/auth/admin.reports.usage.readonly,
  

6. Click Authorize.

Create a Custom Admin Role and Grant Privileges

While still in the Google Admin Console, go to Account > Admin Roles.

7. Click Create new role.

8. Enter the following values:

• Name: Enter an appropriate name, such as Secure Posture Management Read-Only Admin Role.

• Description: Optional

9. Click Continue. The Select Privileges page appears.

   

10. Configure the Select Privileges as follows:

• In Admin Console Privileges, at the top of the page, enable:

  • Organization Units - Read
  • Users - Read

• Scroll down to Admin API Privileges and enable:

  • Groups - Read

• Click Continue. Confirm the 5 privileges.

  

• Click Create Role. The Admin Roles screen appears.

  

11. Click Assign Service Accounts.

12. Enter the Sysdig service account name from step 4 and click Add.

    (Format: sysdig-secure-a1b2@your-project-id.iam.gserviceaccount.com)

    

13. A confirmation screen appears; click Assign Role.

Check Connection Status

To check the connection status:

1. Log in to Sysdig Secure and select Integrations > Cloud Accounts > GCP.
2. Select your project. The Detail panel will open on the right. If the connection is successful, you will see the feature as Connected. This may take up to 5 minutes after deploying the Terraform.