Sysdig Secure for Cloud in Azure

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

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 images that run on the Azure workload (currently AzureContainerInstances).
  Define an AzureRegistry (ACR) through registry_name and also scan all the repository images pushed to the registry.
  Managed through cloud-connector.
  Scanning is disabled by default, can be enabled through deploy_scanning input variable parameters.
  

For other Cloud providers check: AWS , GCP

Usage

There are several ways to deploy Secure for Cloud in you Azure infrastructure,

• /examples for the most common scenarios
  • Single Subscription
  • Single Subscription with a pre-existing Kubernetes Cluster
  • Tenant Subscriptions
  • Many module,examples and use-cases, we provide ways to re-use existing resources (as optionals) in your infrastructure. Check input summary on each example/module.

Find specific overall service arquitecture diagrams attached to each example/use-case.

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.

Notice

• Resource creation inventory Find all the resources created by Sysdig examples in the resource-group sysdig-secure-for-cloud
  
• All Sysdig Secure for Cloud features but Image Scanning are enabled by default. You can enable it through deploy_scanning input variable parameters.
  
• Deployment cost 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!

Required Permissions

Terraform provider credentials/token, requires administrative permissions (Contributor or Owner) in order to be able to create the resources specified in the per-example diagram.

Some components may vary, or may be deployed on different accounts (depending on the example). You can check full resources on each module "Resources" section in their README's. You can also check our source code and suggest changes.

This would be an overall schema of the created resources, for the default setup.

• Event Hub
• Sysdig Workload: Container Instance / For K8s cluter is pre-requied, not create
• For Scanning: Event-Grid, Event Hub, and Enterprise App in the ActiveDirectory
• Sysdig Lighthouse definition for Compliance

Provisioning Roles

• Compliance feature requires Contributor subcription-level role, in order to be able to check specific compliance rules.

  • However, it can be lowered to Reader role, at the cost of failing the control Requirement 9.1 “Ensure App Service Authentication is set up for apps in Azure App Service” from CIS Microsoft Azure Foundations Benchmark) as this needs contributor access to query App Service Auth Settings.

• Threat Detection feature requires Contributor subscription-level role user assignment

  • For AD diagnostic on selected log types Security Administrator role must be granted to at Organizational level.
    • Otherwise, it can be disabled setting deploy_active_directory=false on all examples

• For scanning (disabled by defaul), an App (with its Service Principal) is required to be created in the ActiveDirectory, to enable ContainerRegistry Task to run the image scanning This requires subscription-level Security Administrator role.

Note: Beware that previous roles in AD are found in two different levels; Organizational level (user AD Assigned Roles), and Subscription level (user AD Azure role assignments). This role assignments take some time to consolidate.

Provisioning Permissions

A custom role could be created with following permissions

  # threat-detection
  "Microsoft.Authorization/roleAssignments/*",
  "Microsoft.Authorization/roleDefinitions/*",
  "Microsoft.ContainerInstance/containerGroups/*",
  "Microsoft.ContainerRegistry/checkNameAvailability/read"
  "Microsoft.ContainerRegistry/registries/*",
  "Microsoft.ContainerInstance/locations/operations/read",
  "Microsoft.EventGrid/eventSubscriptions/*",
  "Microsoft.EventHub/namespaces/*",
  "Microsoft.Insights/diagnosticSettings/*",
  "Microsoft.ManagedServices/registrationAssignments/*",
  "Microsoft.ManagedServices/registrationDefinitions/*",
  "Microsoft.Network/networkProfiles/*",
  "Microsoft.Network/networkSecurityGroups/*",
  "Microsoft.Network/virtualNetworks/*",
  "Microsoft.Resources/subscriptions/resourceGroups/*",
  "Microsoft.Resources/subscriptions/resourcegroups/resources/read",
  "Microsoft.ManagedServices/operationStatuses/read",
  "Microsoft.ContainerRegistry/checkNameAvailability/read"

  # image scanning-specific
  "Microsoft.ContainerRegistry/registries/*",
  "Microsoft.ContainerRegistry/checkNameAvailability/read"

Confirm the Services are Working

Check official documentation on Secure for cloud - Azure, Confirm the Services are working

Forcing Events - Threat Detection

Choose one of the rules contained in an activated Runtime Policies for Azure, and execute it in your Azure account.

Alternativelly, use Terraform example module to trigger Azure Access Level creation attempt for Blob Container Set to Public event can be found on examples/trigger-events.

Forcing Events - Image Scanning

• For registry image scanning (ACR), upload any image to a registry repository.

  $ docker login -u xxx -p  xxx your-registry.azurecr.io  # acr access-key user and password
  $ docker tag your-registry.azurecr.io/artifact:tag
  $ docker push your-registry.azurecr.io/artifact:tag

• For workload image scanning in AzureContainerInstances (ACI), deploy any workload to an instance. Azure gives you the option for a quickstart

Troubleshooting

Q-Scanning: I see no image result on Secure

A: 1. Check that the repository where you're uploading images to, is from a registry that has been configured on the deployment, otherwise configure it through registry_name input variable

2. Check that in this registry 'Tasks > Runs' a new image scanning deployment has been spawned
   
3. Check if in the CloudConnector ContainerInstance any log shows that a new image has been detected
   

Q-Azure: Getting Error 403 on Monitor AAD Diagnostic Setting

│ Error: checking for presence of existing Monitor AAD Diagnostic Setting: (Name "iru-aad-diagnostic-setting"):
aad.DiagnosticSettingsClient#Get: Failure responding to request: StatusCode=403
-- Original Error: autorest/azure: Service returned an error.
Status=403 Code="AuthorizationFailed" Message="The client 'iru@***.onmicrosoft.com' with object id '***' does not have authorization to perform action
'microsoft.aadiam/diagnosticSettings/read' over scope '/providers/microsoft.aadiam/diagnosticSettings/iru-aad-diagnostic-setting' or the scope is invalid.
If access was recently granted, please refresh your credentials."

A: Deployment user has not enough permissions to enable AD diagnostic settings for threat-detection.
S: Check Permissions section

Q-Azure: Getting Error 404 could not configure MSI Authorizer: NewMsiConfig: could not validate MSI endpoint

╷
│ Error: could not configure MSI Authorizer: NewMsiConfig: could not validate MSI endpoint: received HTTP status 404
│
│   with provider["registry.terraform.io/hashicorp/azuread"],
│   on main.tf line 1, in provider "azuread":
│    1: provider "azuread" {

A: This may happen if you're using Azure console shell to deploy terraform. MSI (managed service identity has connection limitations)
S: Unset MSI_ENDPOINT environment variable [1]. We will upgrade provider soon to avoid this.

Upgrading

1. Uninstall previous deployment resources before upgrading

$ terraform destroy

2. Upgrade the full terraform example with

$ terraform init -upgrade
$ terraform plan
$ terraform apply

• If the event-source is created throuh SFC, some events may get lost while upgrading with this approach. however, if the cloudtrail is re-used (normal production setup) events will be recovered once the ingestion resumes.

• If required, you can upgrade cloud-connector component by restarting the task (stop task). Because it's not pinned to an specific version, it will download the latest one.

Authors

Module is maintained and supported by Sysdig.

License

Apache 2 Licensed. See LICENSE for full details.