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

With Modular Onboarding, introducing the following design and install structure for terraform-aws-secure:

• [Onboarding]: It onboards an AWS Account or Organization for the first time to Sysdig Secure for Cloud, and collects inventory and organizational hierarchy in the given AWS Organization. Managed through onboarding module.
  

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

• CSPM: It evaluates periodically your cloud configuration, using Cloud Custodian, against some benchmarks and returns the results and remediation you need to fix. Managed through config-posture module.
  

• CDR (Cloud Detection and Response): It sends periodically activity logs to Sysdig by directing those to a dedicated Event Bridge which will be queried by the Sysdig backend to retrieve the data for log ingestion. Enabled via event-bridge integrations module.
  

• Vulnerability Management Agentless Scanning: It uses disk snapshots to provide highly accurate views of vulnerability risk, access to public exploits, and risk management. Managed through agentless-scanning module.
  

For other Cloud providers check: GCP, Azure

These are independent feature modules which deploy and manage all the required Cloud resources and Sysdig resources for the respective Sysdig features. They manage both, onboarding a single AWS Account or an AWS Organization to Sysdig Secure for Cloud.

onboarding, config-posture and agentless-scanning are independent feature modules.

The modules under integrations are feature agnostic modules which deploy and manage all the required Cloud resources and Sysdig resources for shared Sysdig integrations. That is to say, one or more Sysdig features can be enabled by installing an integration.

These modules manage both, onboarding a single AWS Account or an AWS Organization to Sysdig Secure for Cloud.

event-bridge is an integration module.

The modules in this repository can be installed on a single AWS account, or on an entire AWS Organization, or organizational units within the org.

The test directory has sample examples for all these module deployments i.e under single_account, or organization sub-folders.

For example, to onboard a single AWS account, with CSPM enabled, with modular installation :-

1. Run the terraform snippet under test/examples/single_account/onboarding_with_posture.tf with the appropriate attribute values populated.
2. This will install the onboarding module, which will also create a Cloud Account on Sysdig side.
3. It will also install the config-posture module, which will also install cloud resources as well as Sysdig resources for successfully running CSPM scans.
4. On Sysdig side, you will be able to see the Cloud account onboarded with required components, and CSPM feature installed and enabled.

To run this example you need have your aws master-account profile configured in CLI and to execute:

$ terraform init
$ terraform plan
$ terraform apply

Notice that:

• This example will create resources that cost money.
  Run terraform destroy when you don't need them anymore
• All created resources will be created within the tags product:sysdig-secure-for-cloud, within the resource-group sysdig-secure-for-cloud

There are four new parameters to configure organizational deployments on the cloud for Sysdig Secure for Cloud :-

1. include_ouids - List of AWS Organizational Unit IDs to deploy the Sysdig Secure for Cloud resources in.
2. exclude_ouids - List of AWS Organizational Unit IDs to exclude deploying the Sysdig Secure for Cloud resources in.
3. include_accounts - List of AWS Accounts to deploy the Sysdig Secure for Cloud resources in.
4. exclude_accounts - List of AWS Accounts to exclude deploying the Sysdig Secure for Cloud resources in.

DEPRECATION NOTICE: module variables organizational_unit_ids / org_units have been DEPRECATED and are no longer supported. Please work with Sysdig to migrate your Terraform installs to use include_ouids instead to achieve the same deployment outcome.

If new OUs are added in the Include OUIDs list, the existing stackset instances will not get recreated and TF will only create the stackset instances for the newly added OUs.

Note: This applies to only OUs added/removed to/from the organizational configuration. If accounts are added/removed from the Exclude Accounts or Include Extra Accounts list, it will end up recreating the stackset instances.

For contributing to existing modules or adding new modules, below are some of the best practices recommended :-

• Module names referred and used in deployment snippets should be consistent with those in their source path.
• A module can fall into one of two categories - feature module or an integrations module.
• Every user-facing deployment snippet will,
  • at the top level first call the feature module or integrations module from this repo. These modules deploy corresponding cloud resources and Sysdig component resources.
  • the corresponding feature resource will be added as the last block and enabled from the module installed component resource reference. See sample deployment snippets in test/examples for more.
• integrations modules are shared and could enable multiple features. Hence, one should be careful with changes to them.
• Module naming follows the pattern with "-" , resource and variable naming follows the pattern with "_".

A: Make sure you installed both onboarding and event-bridge modules

Module is maintained and supported by Sysdig.

Apache 2 Licensed. See LICENSE for full details.