Skip to main content

Policies

You can create resource-based policies on the DoiT platform that you can use with other DoiT features such as CloudFlow.

Note

Currently, policies can only be used in CloudFlow.

A policy is a set of rules designed to verify compliance on a specific type of resource (for example, a virtual machine or a storage bucket). It can be a simple standalone rule, (storage buckets must be encrypted) or it can be a collection of multiple rules (storage buckets must be encrypted and have a specific tag). The policy is written in Rego. A single policy can be reused across multiple DoiT features, simplifying management and ensuring that a change to one policy automatically applies in every DoiT feature where it is being used.

Rego​

Policies are created using Rego v1 language specification. For security and operational integrity, our platform does not support all the features of the standard Rego language.

Unsupported features​

import statements are not supported. All policy logic must be self-contained within the policy code block. This ensures that the policy remains a single, auditable unit, and prevents external dependencies.

Unsupported built-in functions​

The following built-in functions are not supported.

  • Network access

    • http.send: This function is disabled to prevent unauthorized HTTP requests from policies, mitigating the risk of data exfiltration.

    • net.lookup_ip_addr: This function is disabled to prevent DNS lookups, which could be used for information leakage.

  • Runtime Information Access

    • opa.runtime: This function is disabled to prevent access to the Open Policy Agent (OPA) runtime configuration and environment variables, which could contain sensitive data.

  • Debugging

    • print: This function is disabled to prevent sensitive data from being leaked to the console output.

    • trace: This function is disabled to prevent potential information leakage.

  • External Data Access

    • external_data: This function is disabled to prevent policies from querying external data providers, ensuring that policies only operate on the data explicitly provided to them.

EC2 Security package example​

Below is an example of a policy written in Rego, demonstrating various syntax and rule structures you can use. This policy denys a Terraform deployment if the proposed changes violate three mandatory, high-risk security requirements. The policy checks that:

  • Any standalone aws_ebs_volume resources are not being created that do not have encryption enabled.

  • An EC2 instance does not have any unencrypted root block or EBS block devices.

  • There are no security groups exposing highly sensitive ports to the public internet.

package aws.security

# --- Configuration ---
# Admin ports to keep closed to the world
admin_ports := {22, 3389}

# --- Main Decision Rule ---
default allow := false

# Allow if all required conditions are met
allow if {
	not exists_unencrypted_ebs_volume # 1) No standalone EBS volume is unencrypted
	not exists_instance_with_unencrypted_blocks # 2) No EC2 instance has unencrypted root/ebs devices
	not exists_sg_world_open_admin # 3) No SG exposes admin ports to 0.0.0.0/0
}

# --- Violation Predicates (positive existence checks) ---

# 1) There exists an unencrypted standalone EBS volume
exists_unencrypted_ebs_volume if {
	some rc in input.resource_changes
	startswith(rc.provider_name, "registry.terraform.io/hashicorp/aws")
	rc.change.after != null
	rc.type == "aws_ebs_volume"
	not rc.change.after.encrypted
}

# 2a) There exists an EC2 instance with an unencrypted ROOT volume
exists_instance_with_unencrypted_blocks if {
	some rc in input.resource_changes
	startswith(rc.provider_name, "registry.terraform.io/hashicorp/aws")
	rc.change.after != null
	rc.type == "aws_instance"
	a := rc.change.after
	root_unencrypted(a)
}

# 2b) There exists an EC2 instance with any unencrypted ATTACHED EBS device
exists_instance_with_unencrypted_blocks if {
	some rc in input.resource_changes
	startswith(rc.provider_name, "registry.terraform.io/hashicorp/aws")
	rc.change.after != null
	rc.type == "aws_instance"
	a := rc.change.after
	attached_unencrypted(a)
}

# 3) There exists a security group exposing an admin port to 0.0.0.0/0
exists_sg_world_open_admin if {
	some rc in input.resource_changes
	startswith(rc.provider_name, "registry.terraform.io/hashicorp/aws")
	rc.change.after != null
	rc.type == "aws_security_group"
	some ing in object.get(rc.change.after, "ingress", [])
	some cidr in object.get(ing, "cidr_blocks", [])
	cidr == "0.0.0.0/0"
	p := object.get(ing, "from_port", null)
	p == object.get(ing, "to_port", null)
	p != null
	p in admin_ports
}

# --- Helper Functions ---

# Root block device is present and NOT encrypted
root_unencrypted(a) if {
	rb := object.get(a, "root_block_device", null)
	rb != null
	not rb.encrypted
}

# Any attached EBS block device is NOT encrypted
attached_unencrypted(a) if {
	blks := object.get(a, "ebs_block_device", [])
	some blk in blks
	not blk.encrypted
}

Required permissions​

  • To create a policy, you must have the CloudFlow Editor or CloudFlow Manager permissions.

  • To edit or delete a policy, you must either:

    • have the CloudFlow Manager permission which gives you access to all policies.

    • be the owner of the policy or be assigned as a collaborator. In this case, you must have the CloudFlow Editor permission.

Create a policy​

You must create your policies before you begin using them with any DoiT features.

  1. Sign in to the DoiT console, select Operate from the top navigation bar, and then select Policies.

  2. Select Create policy. The Create a new policy window is displayed.

  3. In Policy name, enter a name that fits the policy's usage, for example, S3 Multipart Upload Cleanup Policy.

  4. (Optional) In Description, enter a description for the policy.

  5. (Optional) In Collaborators, select the email addresses of the users with whom you want to share this policy.

  6. In Create your policy using the Rego language, enter the Rego code to define the rules for your policy. The policy code is compiled when the policy is created. If any errors are found, the policy is not saved.

  7. Select Create.

Add a policy​

Once you have created a policy, you can begin using the policy with your DoiT features.

Add a policy to a CloudFlow​

You can add a policy as a node inside your CloudFlow to automatically check resources against that policy. For example, you could have a CloudFlow that runs on a regular schedule to ensure all S3 buckets have the necessary lifecycle policy for cleaning up incomplete multipart uploads. For each bucket, the flow applies the policy to check that the S3 buckets match the rule, and takes action if not.

Edit policies​

You can edit your policies at any time. The latest version of the policy is automatically used everywhere it is referenced within the DoiT platform.

  1. Sign in to the DoiT console, select Operate from the top navigation bar, and then select Policies.

  2. Select the policy you want to edit. The Edit policy window is displayed.

  3. Update the policy and save your changes.

Delete policies​

You can delete a policy if you are the owner of the policy or you have the CloudFlow Manager permission.

Prerequisites​

A policy cannot be deleted if it is currently in use by any feature on the platform. You must remove the policy you want to delete from all features that are referencing it.

Delete a policy​

Once you have verified the policy is no longer in use:

  1. Sign in to the DoiT console, select Operate from the top navigation bar, and then select Policies.

  2. Select the kebab menu (⋮) at the rightmost end of the policy you want to edit and select Delete.

Last updated on