Add New Features

Configure Cloud Detection and Response (CDR)

CDR detects and responds to threats in real-time within your cloud infrastructure.

Setting up CDR relies on the following GCP features:

• Pub Sub
• Service Account

For additional information on resources created, see Resources created.

Prerequisites

• You must have an GCP Project or Organization already connected to Sysdig. See Connecting GCP Accounts.
• 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. Copy the snippet provided into the log_ingestion.tf file. 3 Run the command: terraform init && 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.

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.

Configure Vulnerability Management

This feature performs vulnerability host scanning using disk Snapshots to provide highly accurate views of vulnerability risk, access to public exploits, and risk management.

Vulnerability Host Scanning relies on the following GCP features:

• Snapshot: Shares disks with Sysdig.

For additional information on resources created, see Resources created.

Prerequisites

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

Volume Access Installation Steps

Use the following steps to set up volume access for Vulnerability Host Scanning for your GCP instances.

1. Log in to Sysdig Secure, select Integrations > Cloud Accounts > GCP.
2. Select a project 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 desired feature to open the wizard.
4. Ensure you have the necessary permissions configured as described in the initial setup.
5. Exclude or Include Resources from Vulnerability Scanning:

• You can exclude resource groups and virtual machines from scans using labels.
• For more information, see how to include/exclude resources.

6. Verify the details of your organization and the project where the features will be added.
7. Generate and apply the Terraform code:
8. Create a volume_access.tf file in the folder that contains your main.tf.
9. Copy the snippet provided into the volume_access.tf file.
10. Run the command: terraform init && terraform apply.

Exclude and Include Resources from Vulnerability Scanning

When you connect a GCP project with Vulnerability Host Scanning, by default all Compute Instances with root volumes in the project are included in the scan.

You can exclude specific Compute Instances from being scanned using labels.

Exclude Instances

To exclude certain Compute Instances from being scanned, you must assign specific labels to them in the GCP Console or using GCP APIs.

Set these labels before initiating the scanning process. If you add labels after onboarding, the exclusion will only take effect in subsequent scans.

Include Data Volumes in Scans

By default, only root volumes of Compute Instances are scanned.

To also include data volumes in scans, you need to use the following specific labels.

Tagging Semantics

You can use the following labels at Volume or Compute Instance level. Tagging can be added at any time, for example, if you want to exclude/include something that was or was not scanned.

Key: sysdig-secure-scan, sysdig-secure-data-volumes-scan.

Values: true, false

Usage Examples

• “sysdig-secure-scan” : “false” on a Compute Instance excludes the instance and all its volumes from scanning
• “sysdig-secure-scan” : “true” on a data-volume of a Compute Instance includes such volume for scanning
• “sysdig-secure-data-volumes-scan” : “true” on a Compute Instance has the same effect as applying the “sysdig-secure-scan” : “true” tag to all its data-volumes.

The following tags are redundant; using them will have the same effect as not having them. This is either because Sysdig scans them by default or because the values have been overridden by a tag at a higher level (such as a Compute Instance).

• “sysdig-secure-scan” : “true” on a Compute Instance
• “sysdig-secure-scan” : “true” on the root volume of a Compute Instance
• “sysdig-secure-scan” : “false” on any data-volumes of a Compute Instance
• “sysdig-secure-scan” : “false” on the root volume of a Compute Instance has no effect. The root volume is always scanned as part of the Compute Instance scan.
• “sysdig-secure-data-volumes-scan” : “false” on a Compute Instance
• “sysdig-secure-data-volumes-scan” : “false” on any data-volumes of a Compute Instance.

Validate

You can verify your Vulnerability Management configuration by checking your connection status:

1. Log in to Sysdig Secure and select Integrations > Cloud Accounts > GCP.
2. Select your account. The Detail panel appears on the right.

You will see the feature as Connected. This may take up to 5 minutes after deploying the Terraform.

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.

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 it is 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 is displayed; click Assign Role.

Complete the Sysdig Onboarding Wizard

When all the enablement steps in GCP consoles are complete, return to the Sysdig wizard and click Complete.

Validate

Log in to Sysdig Secure and check that each module you deployed is functioning. It may take 10 minutes or so for events to be collected and displayed.

Learn More

• Permissions Through Domain-Wide Delegation
• Compliance
• CIEM