Guardrails Pro+

Guardrails enforce infrastructure policies across your repositories, preventing unauthorized or dangerous changes from being applied.

Overview

Guardrails let you define rules that evaluate Terraform plans before they are applied. When a plan violates a guardrail, Controlinfra can block the apply, warn the user, or require approval — depending on the enforcement mode.

Creating a Guardrail

Navigate to Guardrails from the main navigation
Click Create Guardrail
Configure the guardrail:

Field	Description
Name	Descriptive name (e.g., "No Public S3 Buckets")
Description	What this guardrail enforces
Enforcement Mode	How violations are handled
Rules	One or more policy rules
Repositories	Which repos this guardrail applies to

Enforcement Modes

Each guardrail operates in one of four enforcement modes:

Mode	Behavior
Block	Prevents the apply from proceeding. The drift fix or apply is rejected.
Warn	Allows the apply but flags the violation in the UI and notifications.
Dry Run	Evaluates the guardrail and logs results without affecting the apply. Useful for testing new rules.
Require Approval	Pauses the apply until an authorized user approves or rejects it.

TIP

Start with Dry Run mode when creating new guardrails. Review the evaluation results for a few days before switching to Warn or Block.

Rules

Each guardrail contains one or more rules. A guardrail is violated if any rule triggers (OR logic).

Rule Structure

Rules evaluate Terraform plan attributes:

Resource Type: aws_s3_bucket
Attribute: acl
Operator: equals
Value: public-read

Supported Operators

Operator	Description	Example
`equals`	Exact match	`acl equals "public-read"`
`not_equals`	Not an exact match	`engine not_equals "mysql"`
`contains`	String contains	`name contains "prod"`
`not_contains`	String does not contain	`tags not_contains "temporary"`
`regex`	Regular expression match	`name regex "^prod-.*"`
`exists`	Attribute is present	`encryption exists`
`not_exists`	Attribute is absent	`logging not_exists`
`greater_than`	Numeric comparison	`instance_count greater_than 10`
`less_than`	Numeric comparison	`retention_days less_than 30`

Templates

Controlinfra provides built-in guardrail templates for common policies:

Template	Description
No Public S3 Buckets	Blocks S3 buckets with public ACLs or public access
Enforce Encryption	Requires encryption on RDS, S3, EBS, and EFS
Restrict Instance Types	Limits EC2 instance types to an approved list
Require Tags	Enforces mandatory tags on all resources
No Wildcard IAM	Blocks IAM policies with `*` actions or resources
Restrict Regions	Limits resource creation to approved AWS regions

To use a template:

Go to Guardrails → Templates
Select a template
Customize the rules if needed
Set the enforcement mode
Deploy to repositories

Deploying Guardrails

After creating a guardrail, deploy it to one or more repositories:

Open the guardrail detail page
Click Deploy
Select target repositories
Confirm deployment

Once deployed, the guardrail evaluates every Terraform plan in those repositories.

Undeploying

To remove a guardrail from repositories:

Open the guardrail detail page
Click Undeploy
Select repositories to remove
Confirm

Break-Glass Bypass

In emergency situations, authorized users can bypass guardrails:

WARNING

Break-glass bypass is logged in the audit trail and triggers notifications to all org admins. Use only for genuine emergencies.

To bypass a blocked apply:

On the blocked apply screen, click Request Break-Glass Bypass
Provide a justification reason
An admin or owner must approve the bypass
The apply proceeds with the guardrail violation logged

Event Monitoring

All guardrail evaluations are logged and visible in the Guardrails Events section:

Passed: Plan met all guardrail requirements
Violated: Plan triggered one or more rules
Bypassed: Violation was bypassed via break-glass

Events include:

Timestamp
Repository and workspace
Guardrail name and rules triggered
Enforcement action taken
User who initiated the plan

Proactive Enforcement (AWS)

Guardrails can deploy cloud-native policies to prevent changes before they happen.

Prerequisites

AWS proactive enforcement uses one of two control planes depending on your AWS setup:

Path	When to use	Scope
Organizations + SCP	You have (or can create) an AWS Organization	Attaches the SCP to each AWS account ID resolved from the cloud accounts selected on the guardrail. SCPs apply to every principal in those accounts, including root. To make a guardrail apply org-wide, attach the policy to the org root or an OU manually after deploy (Controlinfra does not auto-attach to root).
IAM deny policy (fallback)	Standalone AWS account, or you can't enable Organizations	Single account — applies only to identities the policy is attached to and can be overridden by other admin IAM policies in the same account

TIP

You don't choose between paths in the UI. Controlinfra tries SCP first; if Organizations isn't enabled or the call is denied, it falls back to an account-scoped IAM deny policy automatically.

Option A: AWS Organizations + SCPs (recommended)

This is the AWS-canonical pattern for preventive guardrails. SCPs apply at the org boundary and can't be escaped by IAM policies in member accounts.

1. Enable AWS Organizations. If you don't already have one:

Sign in to the AWS account that will become the management account (typically your billing account).
Open the AWS Organizations console → Create an organization.
Choose "Enable all features" — not "consolidated billing only". SCPs require all features.

WARNING

Switching to "all features" mode is one-way — to revert, you have to dissolve the organization. This is the correct mode for guardrail enforcement.

2. Enable the SCP policy type.

In the Organizations console, open Policies → Service control policies.
Click Enable service control policies.

When SCPs are first enabled, AWS attaches FullAWSAccess to every account by default, so existing workloads keep working until you deploy a deny policy.

3. Grant Controlinfra's IAM identity the required permissions. Attach this policy to the IAM user or role Controlinfra uses for AWS access on the management account:

json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "organizations:CreatePolicy",
        "organizations:UpdatePolicy",
        "organizations:DeletePolicy",
        "organizations:AttachPolicy",
        "organizations:DetachPolicy",
        "organizations:ListPolicies",
        "organizations:ListTargetsForPolicy",
        "organizations:DescribeOrganization",
        "organizations:TagResource",
        "organizations:UntagResource"
      ],
      "Resource": "*"
    }
  ]
}

For alert and dry-run modes (EventBridge-based), also grant:

json

{
  "Effect": "Allow",
  "Action": [
    "events:PutRule",
    "events:PutTargets",
    "events:DeleteRule",
    "events:RemoveTargets",
    "events:DescribeRule",
    "events:ListRules",
    "events:CreateApiDestination",
    "events:DescribeApiDestination",
    "events:DeleteApiDestination",
    "events:CreateConnection",
    "events:DescribeConnection",
    "events:DeleteConnection",
    "events:TagResource",
    "events:UntagResource"
  ],
  "Resource": "*"
}

4. Verify with the permission check. From the guardrail's deploy dialog, run Check enforcement permissions before clicking Deploy. This is a limited preflight — it makes a representative read call against Organizations (ListPolicies) and EventBridge (ListRules) and surfaces missing permissions. It does not validate every action listed above, so make sure the full permission set is granted before deploying or you may still see AccessDeniedException at deploy time.

Management-account hygiene

AWS recommends keeping the management account empty (just billing, Organizations, and IAM Identity Center) and running workloads in member accounts. If your management account currently holds workloads, plan to migrate them over time — but it's fine to start enforcement before that migration is done.

Option B: IAM deny policy (standalone account)

If you can't enable AWS Organizations, Controlinfra falls back to creating an account-scoped IAM deny policy. It's narrower than an SCP — IAM policies can be overridden by other admin policies in the same account, and the deny only takes effect on principals the policy is attached to — but it works on any standalone account with no Organizations setup.

Required IAM permissions:

json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "iam:CreatePolicy",
        "iam:CreatePolicyVersion",
        "iam:DeletePolicy",
        "iam:DeletePolicyVersion",
        "iam:ListPolicyVersions",
        "iam:TagPolicy",
        "iam:UntagPolicy"
      ],
      "Resource": "*"
    }
  ]
}

The EventBridge permissions above are also required if you use alert or dry-run modes.

Deployment Architecture

Block mode → Deploys an AWS SCP (Service Control Policy) or IAM deny policy
Alert mode → Deploys an EventBridge rule with an API Destination pointing to Controlinfra
Dry Run mode → EventBridge rule only — logs events without blocking
Escalation mode → EventBridge initially, SCP deployed dynamically on repeated violations

Security

EventBridge events are authenticated via HMAC-SHA256 signature (X-Guardrail-Signature header)
Each guardrail generates a unique webhook secret on creation
Webhook endpoint is rate-limited (100 requests/minute per IP)
EventBridge targets use API Destinations (not raw URLs) for proper AWS integration

Deployment Safety

Partial deployments are automatically rolled back — if any rule fails to deploy, all successfully deployed policies are removed
SCP attachment validates that specified cloud accounts resolve to valid AWS account IDs
IAM fallback is attempted when Organizations API access is denied
All deployed policies are tagged with controlinfra:guardrail-id for identification

Provider Support

Proactive enforcement is available for AWS and GCP:

AWS — Uses SCP (Service Control Policies) and EventBridge rules as described above
GCP — Uses gcpTranslator.js to convert guardrail rules into GCP Organization Policy constraints and gcpDeployer.js to deploy them. Supports block and alert modes via Organization Policy Service and Cloud Audit Logs
Azure — Works in reactive mode (post-scan evaluation). Azure proactive enforcement is on the roadmap

The UI displays the available enforcement options based on the selected provider.

Bulk Operations

Click Select above the guardrails table to enter selection mode:

Enable / Disable — Bulk toggle guardrails
Delete — Bulk delete with confirmation dialog

Best Practices

Start with Dry Run — Test guardrails before enforcing them
Use templates — Build on proven patterns rather than starting from scratch
Layer enforcement — Use Warn for guidelines, Block for hard requirements
Review events regularly — Monitor for frequent violations that may indicate process gaps
Document justifications — When using break-glass, always provide clear reasons
Check permissions first — Use the permission check tool before deploying enforcement

Guardrails Pro+ ​

Overview ​

Creating a Guardrail ​

Enforcement Modes ​

Rules ​

Rule Structure ​

Supported Operators ​

Templates ​

Deploying Guardrails ​

Undeploying ​

Break-Glass Bypass ​

Event Monitoring ​

Proactive Enforcement (AWS) ​

Prerequisites ​

Option A: AWS Organizations + SCPs (recommended) ​

Option B: IAM deny policy (standalone account) ​

Deployment Architecture ​

Security ​

Deployment Safety ​

Provider Support ​

Bulk Operations ​

Best Practices ​

Next Steps ​

Guardrails Pro+

Overview

Creating a Guardrail

Enforcement Modes

Rules

Rule Structure

Supported Operators

Templates

Deploying Guardrails

Undeploying

Break-Glass Bypass

Event Monitoring

Proactive Enforcement (AWS)

Prerequisites

Option A: AWS Organizations + SCPs (recommended)

Option B: IAM deny policy (standalone account)

Deployment Architecture

Security

Deployment Safety

Provider Support

Bulk Operations

Best Practices

Next Steps