Troubleshoot GCP Agentless Installs

Check for Workload Identity Federation Configuration

GCP Workload Identity Federation (WIFs) can commonly hinder Sysdig’s operation by denying required permissions if they are not correctly configured.

To check for WIFs that may impact Sysdig Integrations (replace PROJECTID and PROJECTNUMBER as needed):

1. Log into GCP console and select the affected project in the homepage.

2. In Workload Identity Pool, the associated Workload Identity Pool provider that’s configured must have an ID with the prefix sysdig-* (Display name doesn’t matter).

3. The configured pool should have a connected service account with the name prefix sysdig-* (as was configured when the account was created). This service account should have the email sysdig-*@PROJECTID.iam.gserviceaccount.com.

4. This service account should allow access to the following principal set:

   • For webhook-datasource: principalSet://iam.googleapis.com/projects/PROJECTNUMBER/locations/global/workloadIdentityPools/sysdig-*/attribute.aws_role/arn:aws:sts::263844535661:assumed-role/us-west-2-production-secure-assume-role/77135e36ab5102091c579abfd9eab3a5

   • For agentless-scan and workload-scan with AWS Sysdig Backend: principalSet://iam.googleapis.com/sysdig-*/attribute.aws_account/<sysdig backend AWS account id>

   • For agentless-scan and workload-scan with GCP Sysdig Backend: principalSet://iam.googleapis.com/sysdig-*/attribute.sa_id/<sysdig backend GCP account id>

5. The service account should have either the iam.serviceAccountTokenCreator role or more specifically iam.serviceAccounts.getAccessToken role, as well as iam.workloadIdentityUser role on the target project. For agentless-scan, it should have a custom role containing the host discovery and host scan related permissions.

6. The pool provider should allow access to the AWS account ID: 263844535661. This is Sysdig’s trusted identity and can be retrieved with curl --location --request GET 'https://us2.app.sysdig.com/api/cloud/v2/gcp/trustedIdentity.

   For scanning (agentless-scan/workload-scan) using GCP Backend, it should allow access to the GCP account ID.

Troubleshoot Agentless CSPM and Identity

• Ensure the service account created in the affected account contains the following roles:
  • browser role.
  • iam.serviceAccountTokenCreator , cloudasset.viewer, logging.viewer, cloudfunctions.viewer and cloudbuild.builds.viewer roles.
• For identity management, ensure the service account has the following roles attached:
  • iam.serviceAccountViewer, recommender.viewer, iam.roleViewer, container.clusterViewer and compute.viewer roles.
• Ensure the service account has a key created and it is enabled.

Troubleshoot Agentless CDR

• Ingestion resources: Ensure the affected account has a pubsub topic (named ingestion_topic), an associated project sink and a push subscription created. (prefixed with ingestion_topic). Organizational installations will have organization sink.
• Ensure the project/organization has audit logs configured to be sent to the pubsub topic.
• Ensure the pubsub topic has pubsub.publisher role attached to publish the ingestion logs.
• Ensure the push subscription has the correct push endpoint configured.

Troubleshoot Agentless Vulnerability Scanning

• To discover compute VPC/Instance/Volume resources, ensure the service account created in the affected account has the host discovery permissions attached.
• To discover compute zone operations and disks resource, ensure the service account created in the affected account has the host scan permissions attached.
• If certain resources (such as compute instances / volumes) are not being scanned, ensure those resources don’t have sysdig-secure-scan/sysdig-secure-data-volumes-scan tags set to false.