Configure CDR and CIEM for GCP
- Pub Sub
- Service Account
To configure CDR and CIEM, set up log ingestion.
Sysdig released a new onboarding experience for GCP in October 2024. If you onboarded your GCP organization and/or project before October, 2024, and would like to add more features, contact your Sysdig representative.
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
- Log in to Sysdig Secure, select Integrations > Cloud Accounts > GCP.
- 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.
- Click Setup beside a feature to open the wizard.
- Verify the details of your organization and the project where the features will be added.
- 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.
- Generate and apply the Terraform code:
- Create a
log_ingestion.tf
file in the folder that contains yourmain.tf
. - Copy the snippet provided into the
log_ingestion.tf
file. - 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.
Retrieve the
log_ingestion.tf
Terraform snippet as described above.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.
- 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] }
- 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] }
- To disable Identity and Access Management, comment out:
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.
Tuning the configuration will change the logs that will be sent to Sysdig. This will affect Sysdig’s runtime visibility and threat detection capabilities.
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 pub-sub
module:
module "pub-sub" {
...
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" }
]
}
]
}
While the Terraform is unique to Sysdig, the configuration affects the project and the logs it generates, which could impact on consumers of those logs. If you want to keep generating these logs, without sending them to Sysdig, you can tune the log filter.
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 pub-sub
module.
This example snippet excludes get
and list methods
for Data Access audit logs:
module "pub-sub" {
...
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 "pub-sub" {
...
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 "pub-sub" {
...
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
Log in to the Google Admin Console with Super Administrator privileges and select Security > Access and data control > API controls.
Click Manage Domain Wide Delegation.
Click Add New.
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.
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,
- Click Authorize.
Create a Custom Admin Role and Grant Privileges
While still in the Google Admin Console, go to Account > Admin Roles.
Click Create new role.
Enter the following values:
Name: Enter an appropriate name, such as
Secure Posture Management Read-Only Admin Role
.Description: Optional
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.
Click Assign Service Accounts.
Enter the Sysdig service account name from step 4 and click Add.
(Format:
sysdig-secure-a1b2@your-project-id.iam.gserviceaccount.com
)A confirmation screen appears; click Assign Role.
Check Connection Status
To check the connection status:
- Log in to Sysdig Secure and select Integrations > Cloud Accounts > GCP.
- 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.
Feedback
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.