Compliance as Code

Targeting Multiple Resource Types

Apply a single compliance control across multiple resource types at once using origin_resource_types arrays.

Edit this page on GitHub

Targeting Multiple Resource Types (Polymorphism)

Applying Controls Efficiently

The origin_resource_types field in standard targets (like attaching new controls or linking to existing resources) natively accepts a list of resource types. This capability adheres to the DRY (Don’t Repeat Yourself) principle, significantly reducing TOML bloat and making governance definitions much easier to maintain.

If you provide a single string, it acts on that single type. If you provide an array, the rule is evaluated across all specified types identically. The Tera templating context (origin_resource) will simply represent the current vertex matching any of the specified types, allowing you to access shared properties seamlessly (e.g. {{origin_resource.name}}).

Relevant Use Cases:

  • Universal Security Policies (MFA, Password Policies): Instead of writing separate targets to attach an MFA policy to admin_user, service_account, and contractor nodes, you can define a single control that maps the security_control node to origin_resource_types = ["admin_user", "service_account", "contractor"].

  • Centralized Infrastructure (Logging / Monitoring): If an organization mandates that all compute resources must forward logs to a central gateway, you want to link them all using a single rule. You can define origin_resource_types = ["server", "vm", "managed_k8s_cluster", "serverless_function"] and link them to the target logging_gateway using a LOGS_TO relation.

  • Corporate Tagging & Labeling Requirements: Many compliance frameworks require strict metadata (e.g., Cost Center, Data Classification, Owner) to be attached to various billable assets. A single rule could target ["subscription", "resource_group", "storage_bucket"] and attach a compliance_audit node to any resource missing these tags or possessing specific tags.