Troubleshoot GCP Agentless Installs

Use the following steps to troubleshoot agentless GCP integration issues.

Check for Workload Identity Federation Configuration

Misconfigured GCP Workload Identity Federation (WIFs) can commonly hinder Sysdig’s operation by denying required permissions. 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-*.

    You can choose any display name.

  3. The configured pool should have a connected service account with the name prefix sysdig-*. This was was configured when the account was created. The 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.workloadIdentityUser 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, such as agentless-scan or workload-scan using the GCP Backend, 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.workloadIdentityUser , 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 that all the resources are correctly deployed in the target project:
    • A Pub/Sub topic prefixed with ingestion_topic.
    • A Log Router (also called sink) sending logs to that topic. Organizational setups will use an aggregate sink.
    • A push subscription created on that topic, prefixed with ingestion_topic.
  • The IAM Logging Service Account service-<PROJECT_ID>@gcp-sa-logging.iam.gserviceaccount.com needs the Pub/Sub Publisher role to publish the ingestion logs on the topic. To find the permissions:
  1. Open the topic in Google Cloud.
  2. Disable Show inherited roles in table.
  3. Ensure the Pub/Sub Publisher role is assigned to the IAM Logging Service Account.

  • Ensure you enable the Cloud Pub/Sub API in the management project.

  • Ensure the push subscription has the correct push endpoint configuration.

  • Ensure you provision the Pub/Sub Service Account for the subscription include the roles/pubsub.serviceAgent role.

    When you enable the Pub/Sub API, you provision the Pub/Sub Service Account with the Cloud Pub/Sub Service Agent role: service-*@gcp-sa-pubsub.iam.gserviceaccount.com. To verify it:

  1. Run the following gcloud command, replacing <PROJECT_ID> with your management project ID:
    gcloud projects get-iam-policy <PROJECT_ID> --flatten="bindings[].members" --format='table(bindings.role, bindings.members)' | grep @gcp-sa-pubsub.iam.gserviceaccount.com
    It should return this line:
    roles/pubsub.serviceAgent serviceAccount:service-<PROJECT_ID_NUMBER>@gcp-sa-pubsub.iam.gserviceaccount.com
    If no line is returned:
  2. Disable and enable the Cloud Pub/Sub API in your management project and check again.
  3. If it’s still not working, from your GCP console:
    1. Open the Subscriptions page on the Pub/Sub service
    2. Select ingestion_topic_push_subscription
    3. If the service agent doesn’t have the right role, you’ll be prompted to assign it through a message. Grant it.

  • Ensure the Sysdig Log ingestion Service Account has been provisioned with the correct roles.

    The Sysdig Log ingestion Service Account can be identified by its email starting with sysdig-ingestion-. It needs to have the roles/iam.workloadIdentityUser role assigned to it. To verify this through the gcloud CLI tool:

    1. Locate the Service Account with the following command:
    gcloud iam service-accounts list --filter="email:sysdig-ingestion*" --format="table(email)"
    1. If the Service Account has been correctly deployed you will be able to copy its email. With that you can then execute the following command (replacing <SA_EMAIL> with the email you just obtained):
    gcloud iam service-accounts get-iam-policy <SA_EMAIL> --format="table(bindings.role) | grep roles/iam.workloadIdentityUser"

    If no line is returned:

  1. From the GCP console disable and enable the subscription authentication:
    1. Open Pub/Sub Subscriptions page
    2. Edit the ingestion_topic_push_subscription subscription
    3. Disable the authentication and hit “Update”
    4. Enable the authentication, selecting the sysdig-ingestion-* Service Account and setting the audience to sysdig_secure
  2. If the previous solution was not successful, remove the current setup with terraform destroy and start from a clean install.

Troubleshoot Agentless Vulnerability Scanning

  • To discover compute Virtual Private Cloud (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.