Skip to main content

Policy Authoring

Policy authoring with Terraform systems allows you to write any Rego you want. For more information on how to use Rego, see the Open Policy Agent website. Styra expects that you are familiar with the Rego concepts of packages and the rules they contain.

Terraform plans enable you to see what changes Terraform needs to make before it makes them. The OPA policies that you write decide whether those changes that Terraform wants to make are safe or not. The basic rules that you write are partial-set rules that either reject or monitor a request. The Terraform type supports the following entry points for the policy: enforce and deny to reject a resource, and monitor and warn to provide a warning.

Each of the partial sets contains either a single string indicating the message to return to the user or an object with the field message. The object can include other fields if you like. The DAS GUI for historical reasons will add allowed: false to the object.

Supported Rules

The following rules are supported when you add the Terraform System.

enforce[decision] {
...
decision := {
"message": "message explaining why there is a problem"
}
}
monitor[decision] {
...
decision := {
"message": "message explaining why there is a problem"
}
}

Supported Formats

For compatibility reasons, the following formats are supported.

deny[decision] {
...
decision := {
"message": "message explaining why there is a problem"
}
}
deny[message] {
...
message := "message explaining why there is a problem"
}
warn[decision] {
...
decision := {
"message": "message explaining why there is a problem"
}
}
warn[message] {
...
message := "message explaining why there is a problem"
}

Pre-built Rules

For example, the pre-built rules in the policy-library are instantiated as follows:

enforce[decision] {
data.global.systemtypes["terraform:0.3"].library.provider.aws.s3.unencrypted.v1.unencrypted_s3_bucket[message]

decision := {
"allowed": false,
"message": message
}
}

For information on writing custom policies, see the Styra Academy or the Open Policy Agent documentation.

Policy Structure

The policies provided in the Terraform system allow you to organize your policies based on the provider and the service within that provider. It provides default policies, but you are free to create, delete, or name those policies as long as you follow the structure shown below:

policy >> provider >> service

All the rules you want enforced must appear within the service policy. Rules added at the provider level or below the service level will not automatically be enforced. However, you can use other directory structures to create helpers for the rules that do get enforced.

For example, you might create the following directory structure. In this case, you can put all your rules into the policies ec2, s3, and vms.

  • policy >> aws >> ec2:

  • policy >> aws >> s3:

  • policy >> gcp >> vms:

You may put tests anywhere within a system. However, Styra typically recommends that you put them in separate packages so that they do not necessarily get downloaded by OPA.

You may also create data sources within the system (under the usual restriction that no data source may appear at a path that is a prefix of a policy path or another data source path). Data sources provide a dedicated location for injecting external data.

The structure of policies within DAS Stacks is the same as the structure of policies within DAS Systems. Whatever rules you put in place at policy >> provider >> service at the stack level are automatically applied to all applicable systems.

note

The actual name of the provider and service are not meaningful in terms of enforcement, except for your organizational purposes. All the rules that appear must ensure they apply only to the appropriate providers and resources within those providers. However, the provider or service names are meaningful to the DAS GUI so that it knows which rules to show you in the Add Rule drop-down list.