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 applyrunMulti-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.
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?
