terraform-policy

Files (55)

• .gitignore
• README.md
• SKILL.md
• README.md · examples/
• README.md · examples/conversion/cloudfront-associated-with-waf/
• cloudfront-associated-with-waf.policy.hcl · examples/conversion/cloudfront-associated-with-waf/
• cloudfront-associated-with-waf.sentinel · examples/conversion/cloudfront-associated-with-waf/
• README.md · examples/conversion/cloudtrail-server-side-encryption-enabled/
• cloudtrail-server-side-encryption-enabled.policy.hcl · examples/conversion/cloudtrail-server-side-encryption-enabled/
• cloudtrail-server-side-encryption-enabled.sentinel · examples/conversion/cloudtrail-server-side-encryption-enabled/
• README.md · examples/conversion/dms-endpoint-should-be-ssl-configured/
• dms-endpoint-should-be-ssl-configured.policy.hcl · examples/conversion/dms-endpoint-should-be-ssl-configured/
• dms-endpoint-should-be-ssl-configured.sentinel · examples/conversion/dms-endpoint-should-be-ssl-configured/
• README.md · examples/conversion/dms-endpoints-should-use-ssl/
• dms-endpoints-should-use-ssl.policy.hcl · examples/conversion/dms-endpoints-should-use-ssl/
• dms-endpoints-should-use-ssl.sentinel · examples/conversion/dms-endpoints-should-use-ssl/
• README.md · examples/conversion/ec2-network-acl-should-have-subnet-ids/
• ec2-network-acl-should-have-subnet-ids.policy.hcl · examples/conversion/ec2-network-acl-should-have-subnet-ids/
• ec2-network-acl-should-have-subnet-ids.sentinel · examples/conversion/ec2-network-acl-should-have-subnet-ids/
• README.md · examples/conversion/ec2-vpc-default-security-group-no-traffic/
• ec2-vpc-default-security-group-no-traffic.policy.hcl · examples/conversion/ec2-vpc-default-security-group-no-traffic/
• ec2-vpc-default-security-group-no-traffic.sentinel · examples/conversion/ec2-vpc-default-security-group-no-traffic/
• README.md · examples/conversion/efs-access-point-should-enforce-user-identity/
• efs-access-point-should-enforce-user-identity.policy.hcl · examples/conversion/efs-access-point-should-enforce-user-identity/
• efs-access-point-should-enforce-user-identity.sentinel · examples/conversion/efs-access-point-should-enforce-user-identity/
• README.md · examples/conversion/elasticache-redis-replication-group-encryption-at-transit-enabled/
• elasticache-redis-replication-group-encryption-at-transit-enabled.policy.hcl · examples/conversion/elasticache-redis-replication-group-encryption-at-transit-enabled/
• elasticache-redis-replication-group-encryption-at-transit-enabled.sentinel · examples/conversion/elasticache-redis-replication-group-encryption-at-transit-enabled/
• README.md · examples/conversion/elasticsearch-encrypted-at-rest/
• elasticsearch-encrypted-at-rest.policy.hcl · examples/conversion/elasticsearch-encrypted-at-rest/
• elasticsearch-encrypted-at-rest.sentinel · examples/conversion/elasticsearch-encrypted-at-rest/
• README.md · examples/conversion/elasticsearch-https-required/
• elasticsearch-https-required.policy.hcl · examples/conversion/elasticsearch-https-required/
• elasticsearch-https-required.sentinel · examples/conversion/elasticsearch-https-required/
• README.md · examples/conversion/elasticsearch-in-vpc-only/
• elasticsearch-in-vpc-only.policy.hcl · examples/conversion/elasticsearch-in-vpc-only/
• elasticsearch-in-vpc-only.sentinel · examples/conversion/elasticsearch-in-vpc-only/
• README.md · examples/conversion/eventbridge-custom-event-bus-should-have-attached-policy/
• eventbridge-custom-event-bus-should-have-attached-policy.policy.hcl · examples/conversion/eventbridge-custom-event-bus-should-have-attached-policy/
• eventbridge-custom-event-bus-should-have-attached-policy.sentinel · examples/conversion/eventbridge-custom-event-bus-should-have-attached-policy/
• README.md · examples/conversion/s3-block-public-access-bucket-level/
• s3-block-public-access-bucket-level.policy.hcl · examples/conversion/s3-block-public-access-bucket-level/
• s3-block-public-access-bucket-level.sentinel · examples/conversion/s3-block-public-access-bucket-level/
• README.md · examples/conversion/s3-bucket-should-have-object-lock-enabled/
• s3-bucket-should-have-object-lock-enabled.policy.hcl · examples/conversion/s3-bucket-should-have-object-lock-enabled/
• s3-bucket-should-have-object-lock-enabled.sentinel · examples/conversion/s3-bucket-should-have-object-lock-enabled/
• README.md · examples/conversion/secretsmanager-auto-rotation-enabled-check/
• secretsmanager-auto-rotation-enabled-check.policy.hcl · examples/conversion/secretsmanager-auto-rotation-enabled-check/
• secretsmanager-auto-rotation-enabled-check.sentinel · examples/conversion/secretsmanager-auto-rotation-enabled-check/
• README.md · examples/conversion/step-functions-state-machine-logging-enabled/
• step-functions-state-machine-logging-enabled.policy.hcl · examples/conversion/step-functions-state-machine-logging-enabled/
• step-functions-state-machine-logging-enabled.sentinel · examples/conversion/step-functions-state-machine-logging-enabled/
• tfpolicy-author.md · references/
• tfpolicy-test.md · references/
• verified-syntax.md · references/

SKILL.md (first lines)

# terraform-policy

**UTILITY SKILL** — INVOKES: [tfpolicy-author](references/tfpolicy-author.md) | [tfpolicy-test](references/tfpolicy-test.md)

## USE FOR:

- Writing a new `.policy.hcl` policy from a description or requirement
- Converting a `.sentinel` policy to Terraform Policy
- Writing or debugging a `.policytest.hcl` test file
- Migrating a Sentinel policy library to Terraform Policy

Before giving authoring or testing instructions, check the installed `tfpolicy` CLI version and tailor guidance accordingly. This skill maintains guidance for the two most recent minor lines, `0.4.x` and `0.5.x`. The `0.3.x` bullet below is baseline guidance that applies to every supported line. When a new minor ships, drop the oldest line and add the new one. Inline notes for versions earlier than `0.3.0` are retained only for older CLIs.
- If the CLI is `0.3.x` (baseline), include a top-level `policy { required_providers { ... } }` block when authoring `.policy.hcl` files containing resource or provider policies. It is mandatory for `tfpolicy validate`; version-range validation is best effort, and wildcard targets such as `resource_policy "*"` are not schema-validated. Every mock `resource {}` block in `.policytest.hcl` files must declare `attrs` or `prior_attrs`; if both evaluate to empty, the test case is skipped (`provider {}` and `module {}` mocks are unaffected) (see [tfpolicy-test](references/tfpolicy-test.md#every-resource--mock-must-declare-a-non-empty-state-block-tfpolicy-030)). `tfpolicy test` reuses the target `.policy.hcl`'s existing top-level `policy { required_providers { ... } }` block (there is no separate `.policytest.hcl`-level declaration) to validate provider, resource, and data-source policies and `core::getdatasource()`/`core::getresources()` arguments against resolved provider schemas before any test runs, failing the whole run on a schema mismatch (see [tfpolicy-test](references/tfpolicy-test.md#test-execution-behavior)). `core::alltrue(list)` and `core::anytrue(list)` are available — prefer them over the `core::length()` list-comprehension workaround (see [tfpolicy-author](references/tfpolicy-author.md#core-functions--common-idioms)). `meta.tfe_stack` and `meta.tfe_workspace.tags` are available to resource, provider, and module policies; Stack fields are empty strings outside Stack evaluations on 0.3.x and 0.4.x (`null` on 0.5.x+, see below). On 0.3.x only, the `no-op` operation does not exist: resource policies evaluate only resources that the run creates, updates, or deletes, and the default `operations` is `["create", "update"]`.
- If the CLI is `0.4.x` or newer, all `0.3.x` guidance still applies except the `operations` default, plus the `no-op` operation, which evaluates resources that the run leaves unchanged (the entire state). `operations` accepts `"create"`, `"update"`, `"delete"`, and `"no-op"`. For policies that do not reference `prior_attrs`, the default `operations` is now `["create", "update", "no-op"]`, so omitting it evaluates every resource in state. Use `operations = ["create", "update"]` to evaluate only changed resources. `no-op` exposes the existing values through `attrs`, and `prior_attrs` is unavailable. `delete` cannot be combined with `create` or `no-op` (`["update", "delete"]` is valid), and `prior_attrs` policies must set `operations` explicitly. Attrs-only policies (no `prior_attrs`) calling `core::getresources` whose `operations` omit `no-op` load with a warning; do not add `no-op` to a `prior_attrs` policy, which fails validation. In tests, set `meta.operation = "no-op"` explicitly because it is never inferred (see [tfpolicy-author](references/tfpolicy-author.md#operation-scoping-and-prior_attrs) and [tfpolicy-test](references/tfpolicy-test.md#testing-operation-aware-policies)).
- If the CLI is `0.5.x` or newer, all `0.4.x` guidance still applies, with two changes. (1) Absent `meta` attributes are exposed as `null` instead of an empty string: `meta.alias` (no alias), `meta.version` (no version specified, including modules), and `meta.tfe_stack.deployment_group` / `deployment_name` / `stack_name` (workspace evaluations or not set). `meta.tfe_workspace.tags` is still an empty map. Passing `null` to a function such as `core::semverconstraint`, or interpolating it into a string such as `error_message`, fails, and `&&` does not short-circuit, so guard with a conditional: `meta.version != null ? core::semverconstraint(meta.version, ">= 2.0.0") : false`. Equality checks are null-safe (`meta.alias == "secondary"` is `false` when there is no alias), but checks like `meta.tfe_stack.stack_name == ""` no longer match (use `== null`). (2) `prior_attrs` is rejected at parse time in `provider_policy` and `module_policy` blocks; it is valid only in `resource_policy` (update and delete operations). Use `attrs.` for provider attributes (see [tfpolicy-author](references/tfpolicy-author.md#meta-attributes-nullable-on-050)).
- If the CLI version is unknown, ask the user to check it first or provide guidance that clearly distinguishes the `0.3.x`, `0.4.x`, and `0.5.x` paths.

## DO NOT USE FOR:

- Writing `.tftest.hcl` files for Terraform modules — use `terraform-test`
- General Terraform HCL authoring — use `terraform-style-guide`

## Routing

| Task | Sub-skill |
|------|-----------|
| Write or convert a `.policy.hcl` policy | [tfpolicy-author](references/tfpolicy-author.md) |
| Write or debug a `.policytest.hcl` test | [tfpolicy-test](references/tfpolicy-test.md) |

## Examples

- "Block EC2 instances without encryption" → [tfpolicy-author](references/tfpolicy-author.md)
- "Convert this Sentinel policy to tfpolicy" → [tfpolicy-author](references/tfpolicy-author.md)
- "Write a policytest for my EBS policy" → [tfpolicy-test](references/tfpolicy-test.md)

## Troubleshooting

- **Wrong skill triggered?** Load the sub-skill directly from the routing table above.

```bash
npx skills add hashicorp/agent-skills/terraform/terraform-policy/skills/tfpolicy-author
npx skills add hashicorp/agent-skills/terraform/terraform-policy/skills/tfpolicy-test
```

From hashicorp/agent-skills, MPL-2.0.

More from hashicorp/agent-skills