Fix cloud issues in IaC

Release status

The fix cloud issues in IaC feature is available for IaC+ only and supports AWS, Azure, and Google Cloud.

Snyk IaC+ is now in closed beta and is no longer accepting new customers for participation. See Getting started with current IaC for details about the functionality available.

The fix cloud issues in IaC feature enables users to fix cloud issues directly in the IaC source code used to deploy the misconfigured cloud resources, by linking a cloud issue to the underlying IaC template via an SCM source code link.

Many Snyk customers use IaC to deploy and manage cloud resources. However, organizations may still deploy misconfigured IaC templates, which results in misconfigured cloud resources and therefore cloud context issues. This can be due to a number of factors, such as pipelines that are not configured to block deployments even if cloud misconfigurations are found.

To remediate these cloud issues, security teams have determined manually which teams own the resources that were incorrectly deployed, and then developers manually found the appropriate IaC templates that were used. This can be a very time-consuming process.

This feature eliminates these manual steps and provides the user with a link to the underlying IaC template that needs to be fixed.

How does fix cloud issues in IaC work?

Snyk delivers this capability by “mapping” cloud resources to the source IaC templates where possible. Snyk does this by leveraging information contained in Terraform state files, such as resource IDs, which enable Snyk to map Cloud resources to Terraform state, and Terraform state to IaC source code.

Snyk accesses Terraform state files via the CLI, which should be integrated into your deployment pipeline. Snyk does NOT send the .tfstate file to the Snyk Platform, given the potential for sensitive information. Instead, Snyk obtains the minimum amount of data necessary for resource mapping, such as resource IDs, and includes this information in a mapping artifact that is sent to the Snyk Platform. All other configuration data is not included in the mapping artifact.

Snyk generates resource mappings from cloud resources to IaC source templates by analyzing mapping artifacts, cloud resources, and IaC resources when cloud environments are scanned.

Prerequisites for fix cloud issues in IaC

You must have the following:

  • Access to a Snyk service account and API token

  • Access to a Snyk Organization with IaC+

  • Cloud resources deployed to AWS, Azure, and/or Google Cloud with Terraform via CI/CD

  • Terraform version 0.11 or later

Steps in fixing cloud issues in IaC

Step 1: Onboard IaC and cloud environments to Snyk

Onboard IaC+ environments via the Snyk CLI workflow (snyk iac test --report), and onboard relevant cloud environments via AWS Integration, Azure Integration, or Google Cloud Integration.

snyk iac test must be run from the root folder of the cloned Git repository, not a subdirectory. If you are using GitLab or Azure DevOps, add a target-reference option so Snyk can generate an SCM link, as in the following CLI command:

snyk iac test --report --target-reference=$(git branch --show-current)

These cloud environments: AWS, Azure, or Google Cloud, should include resources deployed with Terraform via your CI/CD tool.

Step 2: Configure CI/CD pipeline script

Configure a CI/CD script to:

  • Pull down the Terraform state via terraform state pull

  • Install the Snyk CLI and run snyk iac capture with relevant options.

Snyk offers sample CI/CD scripts for your reference in the sections that follow.

GitHub Actions example

Set the following environment variables in GitHub as encrypted repository secrets:

  • AWS_ACCESS_KEY_ID - used for terraform apply and terraform state pull

  • AWS_SECRET_ACCESS_KEY - used for terraform apply and terraform state pull

  • SNYK_TOKEN - the Snyk service account's API token

  • SNYK_ORG_ID - the Snyk Organization ID

name: continuous-delivery
on:
  push:
    branches:
      - main
jobs:
  delivery:
    runs-on: ubuntu-latest
    env:
      AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
      AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
      SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
    steps:
      - uses: actions/checkout@v3
      - uses: hashicorp/setup-terraform@v2
        with:
          terraform_wrapper: false
      - uses: snyk/actions/setup@master
      - run: terraform init

      - name: terraform plan
        run: terraform plan -input=false

      # Always report misconfigurations and continue with job
      - name: snyk iac test
        run: snyk iac test --org=${{ secrets.SNYK_ORG_ID }} --report || true

      - name: terraform apply
        run: terraform apply -auto-approve -input=false

      - name: capture terraform state
        run: terraform state pull | snyk iac capture --org=${{ secrets.SNYK_ORG_ID }} --stdin

CircleCI example

Set the following environment variables in CircleCI:

  • AWS_ACCESS_KEY_ID - used for terraform apply and terraform state pull

  • AWS_SECRET_ACCESS_KEY - used for terraform apply and terraform state pull

  • SNYK_TOKEN - the Snyk service account's API token

  • SNYK_ORG_ID - the Snyk Organization ID

version: 2.1

orbs:
  terraform: circleci/terraform@3.2.0
  snyk: snyk/snyk@1.5.0
jobs:
  delivery:
    machine:
      image: ubuntu-2204:current
    resource_class: medium
    steps:
      - checkout
      - terraform/install:
          terraform_version: 1.4.2
      - snyk/install

      - terraform/plan

      - run:
          name: snyk iac test
          command: snyk iac test --org=$SNYK_ORG_ID --report || true

      - terraform/apply
      
      - run:
          name: capture terraform state
          command: terraform state pull | snyk iac capture --org=$SNYK_ORG_ID --stdin

workflows:
  continuous-delivery:
    jobs:
      - delivery

Step 3: Run the pipeline

By running your CI/CD pipeline to pull Terraform state and run snyk iac capture, Snyk generates a mapping artifact with a minimal amount of information from the Terraform state file and sends it to Snyk.

When a mapping artifact is created or updated, Snyk executes a mapping run by analyzing IaC resources, cloud resources, and mapping artifacts across a Snyk Organization, and generates resource mappings that include connections between cloud and IaC resources.

Step 4: Wait a few minutes, and check the cloud issues page

Wait a few minutes so that Snyk can finish the cloud environment scan, complete the mapping run, and update resource mappings.

Navigate to the cloud issues page, and set the has_iac_mappings filter to true, either in the search bar or by selecting the appropriate filter. This will display cloud issues with resources that are mapped to IaC resources, for supported resource types.

Relevant cloud Issues should now include mapped IaC resources within the IaC tab. Each IaC resource includes information on the resource name, IaC template location, and where available, a link to the SCM tool.

Supported resource types

The following is a list of resource types that have been verified to be supported.

AWS

  • aws_api_gateway_deployment

  • aws_api_gateway_resource

  • aws_api_gateway_rest_api

  • aws_cloudtrail

  • aws_cloudwatch_log_group

  • aws_db_instance

  • aws_db_subnet_group

  • aws_default_security_group

  • aws_default_vpc

  • aws_dynamodb_table

  • aws_ebs_volume

  • aws_eip

  • aws_flow_log

  • aws_iam_access_key

  • aws_iam_group

  • aws_iam_group_policy

  • aws_iam_group_policy_attachment

  • aws_iam_instance_profile

  • aws_iam_policy

  • aws_iam_policy_attachment

  • aws_iam_role

  • aws_iam_role_policy

  • aws_iam_role_policy_attachment

  • aws_iam_user

  • aws_iam_user_policy

  • aws_iam_user_policy_attachment

  • aws_instance

  • aws_internet_gateway

  • aws_kms_key

  • aws_lambda_function

  • aws_lambda_permission

  • aws_network_acl

  • aws_network_interface

  • aws_rds_cluster

  • aws_rds_global_cluster

  • aws_route_table

  • aws_route_table_association

  • aws_s3_account_public_access_block

  • aws_s3_bucket

  • aws_s3_bucket_acl

  • aws_s3_bucket_logging

  • aws_s3_bucket_policy

  • aws_s3_bucket_public_access_block

  • aws_s3_bucket_server_side_encryption_configuration

  • aws_security_group

  • aws_security_group_rule

  • aws_sns_topic

  • aws_subnet aws_vpc

Azure

  • azurerm_resource_group

  • azurerm_storage_account

  • azurerm_sql_active_directory_administrator

  • azurerm_network_interface

  • azurerm_subnet

  • azurerm_virtual_machine_extension

  • azurerm_virtual_network

  • azurerm_managed_disk

  • azurerm_subscription_policy_assignment

  • azurerm_storage_data_lake_gen2_filesystem

  • azurerm_synapse_firewall_rule

  • azurerm_synapse_workspace

  • azurerm_storage_account_network_rules

  • azurerm_service_fabric_cluster

  • azurerm_security_center_auto_provisioning

  • azurerm_security_center_contact

  • azurerm_search_service

  • azurerm_network_security_group

  • azurerm_network_security_rule

  • azurerm_key_vault

  • azurerm_mssql_server_security_alert_policy

  • azurerm_mariadb_server

  • azurerm_postgresql_firewall_rule

  • azurerm_postgresql_server

  • azurerm_mysql_firewall_rule

  • azurerm_mysql_server

  • azurerm_linux_virtual_machine

  • azurerm_windows_virtual_machine

  • azurerm_mssql_server

  • azurerm_mssql_server_extended_auditing_policy

Google Cloud

  • google_logging_project_sink

  • google_storage_bucket

  • google_bigquery_dataset

  • google_dns_managed_zone

  • google_compute_instance_template

  • google_compute_instance

  • google_service_account

  • google_compute_network

  • google_compute_subnetwork

  • google_compute_ssl_policy

  • google_compute_project_metadata

  • google_compute_firewall

  • google_compute_disk

  • google_kms_crypto_key

  • google_sql_user

Last updated

More information

Snyk privacy policy

© 2024 Snyk Limited | All product and company names and logos are trademarks of their respective owners.