Sysdig Secure for Cloud in GCP

Terraform module that deploys the Sysdig Secure for Cloud stack in Google Cloud.

Provides unified threat-detection, compliance, forensics and analysis through these major components:

Threat Detection: Tracks abnormal and suspicious activities in your cloud environment based on Falco language. Managed through cloud-connector module.
Compliance: Enables the evaluation of standard compliance frameworks. Requires both modules cloud-connector and cloud-bench.
Image Scanning: Automatically scans all container images pushed to the registry (GCR) and the images that run on the GCP workload (currently CloudRun). Managed through cloud-connector.
Disabled by Default, can be enabled through deploy_scanning input variable parameters.

For other Cloud providers check: AWS, Azure

Notice

GCP regions
All Sysdig Secure for Cloud features but Image Scanning are enabled by default. You can enable it through deploy_scanning input variable parameter of each example.
This example will create resources that cost money. Run terraform destroy when you don't need them anymore.
For free subscription users, beware that organizational examples may not deploy properly due to the 1 cloud-account limitation. Open an Issue so we can help you here!

Prerequisites

You must have following roles in your GCP credentials

Owner
Organization Admin (organizational usage only)

Besides, the following GCP APIs must be enabled to deploy resources correctly for:

Cloud Connector

Cloud Scanning

Cloud Benchmarks

Usage

If you're unsure about what/how to use this module, please fill the questionnaire report as an issue and let us know your context, we will be happy to help and improve our module.

- Single-Project

Sysdig workload will be deployed in the same account where user's resources will be watched.
More info in ./examples/single-project

- Single-Project with a pre-existing Kubernetes Cluster

If you already own a Kubernetes Cluster on GCP, you can use it to deploy Sysdig Secure for Cloud, instead of default CloudRun.
More info in ./examples/single-project-k8s

- Organization

Using an organization to collect all the AuditLogs. More info in ./examples/organization

- Self-Baked

If no examples fit your use-case, be free to call desired modules directly.

In this use-case we will ONLY deploy cloud-bench, into the target account, calling modules directly

provider "google" {
  project = "PROJECT-ID"
  region = "REGION"
}

provider "google-beta" {
  project = "PROJECT-ID"
  region = "REGION"
}

provider "sysdig" {
  sysdig_secure_url         = "<SYSDIG_SECURE_URL>"
  sysdig_secure_endpoint    = "<SYSDIG_SECURE_API_TOKEN>"
}

module "cloud_bench" {
  source      = "sysdiglabs/secure-for-cloud/google//modules/services/cloud-bench"
}

See inputs summary or main module variables.tf file for more optional configuration.

To run this example you need have your google cloud profile configured:

$ terraform init
$ terraform plan
$ terraform apply

Forcing Events

Threat Detection

Terraform example module to trigger GCP Update, Disable or Delete Sink event can be found on examples/trigger-events

In another case, you can do it manually. Choose one of the rules contained in the GCP Best Practices policy and execute it in your GCP account. ex.: Create an alert (Monitoring > Alerting > Create policy). Delete it to prompt the event.

Remember that in case you add new rules to the policy you need to give it time to propagate the changes.

In the cloud-connector logs you should see similar logs to these

An alert has been deleted (requesting user=..., requesting IP=..., resource name=projects/test/alertPolicies/3771445340801051512)

Image Scanning

For Repository image scanning, upload an image to a new Repository in a Artifact Registry. Follow repository Setup Instructions provided by GCP

$ docker tag IMAGE:VERSION REPO_REGION-docker.pkg.dev/PROJECT-ID/REPOSITORY/IMAGE:latest
$ docker push REPO_REGION-docker.pkg.dev/PROJECT-ID/REPOSITORY/IMAGE:latest

For CloudRun image scanning, deploy a runner.

It may take some time, but you should see logs detecting the new image in the cloud-connector logs, similar to these

An image has been pushed to GCR registry (project=..., tag=europe-west2-docker.pkg.dev/test-repo/alpine/alpine:latest, digest=europe-west2-docker.pkg.dev/test-repo/alpine/alpine@sha256:be9bdc0ef8e96dbc428dc189b31e2e3b05523d96d12ed627c37aa2936653258c) Starting GCR scanning for 'europe-west2-docker.pkg.dev/test-repo/alpine/alpine:latest

And a CloudBuild being launched successfully.

Troubleshooting

Q: Why do we need `google-beta` provider?

A: Some resources we use, such as the google_iam_workload_identity_pool_provider are only available in the beta version.

Q: Getting "Error creating WorkloadIdentityPool: googleapi: Error 409: Requested entity already exists"

A: Currently Sysdig Backend does not support dynamic WorkloadPool and it's name is fixed to sysdigcloud.
Besides, Google, only performs a soft-deletion of this resource. https://cloud.google.com/iam/docs/manage-workload-identity-pools-providers#delete-pool

You can undelete a pool for up to 30 days after deletion. After 30 days, deletion is permanent. Until a pool is permanently deleted, you cannot reuse its name when creating a new workload identity pool.

S: For the moment, federation workload identity pool+provider have fixed name. In case you want to reuse it, you can reactivate and import it, into your terraform state manually.

# re-activate pool and provider
$ gcloud iam workload-identity-pools undelete sysdigcloud  --location=global
$ gcloud iam workload-identity-pools providers undelete sysdigcloud --workload-identity-pool="sysdigcloud" --location=global

# import to terraform state
# for this you have to adapt the import resource to your specific usage
# ex.: for single-project, input your project-id
$ terraform import 'module.secure-for-cloud_example_single-project.module.cloud_bench[0].module.trust_relationship["<YOUR_PROJECT_ID>"].google_iam_workload_identity_pool.pool' sysdigcloud
$ terraform import 'module.secure-for-cloud_example_single-project.module.cloud_bench[0].module.trust_relationship["<YOUR_PROJECT_ID>"].google_iam_workload_identity_pool_provider.pool_provider' sysdigcloud/sysdigcloud

# ex.: for organization example you should change its reference too, per project
$ terraform import 'module.secure-for-cloud_example_organization.module.cloud_bench[0].module.trust_relationship["<YOUR_PROJECT_ID>"].google_iam_workload_identity_pool.pool' sysdigcloud
$ terraform import 'module.secure-for-cloud_example_organization.module.cloud_bench[0].module.trust_relationship["<YOUR_PROJECT_ID>"].google_iam_workload_identity_pool_provider.pool_provider' sysdigcloud/sysdigcloud

Q: Getting "Error creating Topic: googleapi: Error 409: Resource already exists in the project (resource=gcr)"

│ Error: Error creating Topic: googleapi: Error 409: Resource already exists in the project (resource=gcr).
│
│   with module.sfc_example_single_project.module.pubsub_http_subscription.google_pubsub_topic.topic[0],
│   on ../../../modules/infrastructure/pubsub_push_http_subscription/main.tf line 10, in resource "google_pubsub_topic" "topic":
│   10: resource "google_pubsub_topic" "topic" {

A: This error happens due to a GCP limitation where only a single topic named gcr can exist. This name is gcp hardcoded and is the one we used to detect images pushed to the registry.
S: If the topic already exists, you can import it in your terraform state, BUT BEWARE that once you call destroy it will be removed.

$ terraform import 'module.sfc_example_single_project.module.pubsub_http_subscription.google_pubsub_topic.topic[0]' gcr

Q: Getting "Cloud Run error: Container failed to start. Failed to start and then listen on the port defined by the PORT environment variable."

A: If cloud-connector cloud run module cannot start it will give this error. The error is given by the health-check system, it's not specific to its PORT per-se S: Verify possible logs before the deployment crashes. Could be limitations due to Sysdig license (expired trial subscription or free-tier usage where cloud-account limit has been surpassed)

Q: Scanning does not seem to work

A: Verify that gcr topic exists. If create_gcr_topic is set to false and gcr topic is not found, the GCR scanning is omitted and won't be deployed. For more info see GCR PubSub topic.

Q: Getting "message: Cloud Run error: Container failed to start. Failed to start and then listen on the port defined by the PORT environment variable"

A: Contrary to AWS, Terraform Google deployment requires just-started workload to start in a healthy status. If this does not happen it will fail.
S: Check your workload services (cloud run) logs to see what really failed. One common cause is a wrong Sysdig Secure API Token

Q: Scanning, I get an error saying:

error starting scan runner for image ****: rpc error: code = PermissionDenied desc = Cloud Build API has not been used in project *** before or it is disabled.
Enable it by visiting https://console.developers.google.com/apis/api/cloudbuild.googleapis.com/overview?project=*** then retry.

If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry

A: Do as the error says and activate CloudBuild API. Check the list of all the required APIs that need to be activated per feature module.

Authors

Module is maintained and supported by Sysdig.

License

Apache 2 Licensed. See LICENSE for full details.

trlinkin/terraform-google-secure-for-cloud