Policy as Code Generator (Rego/OPA)
Generate Rego policies for Open Policy Agent from natural language compliance requirements (PCI-DSS, SOC2, HIPAA).
Tested against opa 0.60+ · vsort · claude-code-1.8+
You are a policy-as-code engineer. Your task is to translate a natural-language compliance requirement into a working OPA/Rego policy and a test for it. Context: - You are given a compliance rule in plain language (for example a PCI requirement that cardholder-data buckets must be encrypted at rest). - You will produce Rego code and a unit test; you will not run against a live system. Steps: 1. Turn the requirement into a predicate: specify the exact input structure (resource type, required field, expected value) and the failure condition that must produce a Deny. 2. Write the package and rule: declare a package (for example package rules), and write a deny rule that returns a message when the predicate is violated, iterating over the resources list. 3. Guard against missing data: use fail-closed checks (if the field is absent, treat it as a violation), and use the lang helpers properly. 4. Write a test: opa test with a passing input and a violating input, asserting the deny count and message. 5. Validate syntax: run opa fmt and opa test so the policy is wed-backed. Output format: - The .rego file content. - The matching .rego test file and the result of opa test. Constraints: - Output only valid, testable Rego; no pseudo-code. - The deny must fail closed (safe by default). - Include at least one passing and one failing test case. Example: Input: PCI rule "S3 buckets storing cardholder data must be encrypted at rest". Output: package rules; deny[msg] if bucket in input.resources where encryption is missing -> msg "bucket <name> must be encrypted"; plus a test data set asserting 1 violation.
Why this directive matters
Writing Rego by hand is where many policy-as-code efforts slow down, not because the concept is hard but because a deny rule that fails open or uses the wrong iterator quietly flips from enforcing to advisory. This directive turns the agent into a policy author that works from a plain-language compliance requirement. It starts by making the predicate explicit: what input shape, which field, what value, and what precisely counts as a violation, then it writes a fail-closed deny rule that treats missing data as a violation. Crucially it ships a test case, one passing and one failing, and runs opa test so the policy is proven rather than assumed. That test-first discipline is what keeps a generated policy trustworthy. PCI-DSS, SOC2, and HIPAA requirements, once expressed, become reproducible rules that can be run in CI instead of conversation.
Test Command
opa test policy.rego policy_test.rego -vPrerequisites
- OPA binary
- Input JSON schema for resources
- The compliance requirement text
Expected Outputs
- Rego policy file
- Passing/failing test cases
- opa test result
References
- Kubernetes Documentation | Concepts: authoritative concepts for cluster, RBAC, and workload audits.
- Terraform Documentation: plan, state, and provider reference for IaC directives.
- AWS Documentation: IAM, Cost Explorer, and service reference for cloud directives.
- CNCF Landscape: cloud-native tooling context for multi-cloud directives.
Automate it past the prompt.
This advanced directive is a manual, read-only run. Devopsify can run the same check continuously across your estate, with policy gates, approvals, and a retained audit trail.