For the complete documentation index, see llms.txt. This page is also available as Markdown.

Reference B: GitOps and infrastructure-as-code (IaC)

For modern cloud-native environments, managing security configurations via infrastructure as code (IaC) prevents drift and ensures auditability. The Cortex Terraform provider exposes the cortexcloud_appsec_data_source_instance resource to manage third-party scanner connections declaratively as code.

For more information on the Cortex Terraform provider, refer to https://github.com/cortexapps/terraform-provider-cortex.

When to use the Terraform provider

Managing integrations through the Cortex Terraform Provider is highly recommended for:

  • Drift-free configurations: Locks down integration properties, ensuring that ad-hoc manual changes in the UI are automatically caught and reverted during the next terraform apply run

  • Multi-repository pipelines: Simplifies mapping management when spinning up new services. You can declare repository mappings directly inside your microservice provisioning templates

  • Multi-tenant sync: Maintains identical integration definitions and scan configurations across staging, pre-production, and production Cortex Cloud tenants

Declarative resource example

This resource block example demonstrates how to provision and configure a Checkmarx One integration with automatic future mapping enabled.

resource "cortexcloud_appsec_data_source_instance" "checkmarx_us" {
  vendor = "CHECKMARX"

  configuration {
    tenant_url = "https://ast.checkmarx.net"
    api_key    = var.checkmarx_api_key
  }

  scan_types = ["SAST", "SCA"]

  mappings {
    auto_map_future_projects = true
  }
}

Common Terraform patterns

When managing integrations at scale, adopt these standard architecture patterns in your IaC repositories.

Pattern
Description

Secret-managed API key

Source the third-party API key from a secret manager (HashiCorp Vault, AWS Secrets Manager, Terraform Cloud variable sets) rather than committing the key to version control

Multi-tenant fan-out

Use Terraform workspaces or modules with for_each over a tenant map to deploy the same third-party integration configuration across multiple Cortex Cloud tenants

Drift detection

Run terraform plan on a schedule to detect manual UI edits to managed third-party instances (for example, mapping changes or scan-type toggles)

Module encapsulation

Encapsulate the third-party instance, scan-type selections, and mapping configuration as a reusable Terraform module per third-party tenant

Last updated

Was this helpful?