Guardrails: Scalable policies for cloud infrastructure

Guardrails are policies that keep your cloud infrastructure healthy and secure. Designed to be easy to build and maintain, they integrate into your change management and safeguard against bad configuration from ever making it into production: keeping developers on track without risking the security and stability of your cloud.

When an infrastructure-as-code commit is submitted, it is checked to see if it violates relevant Guardrails. If it does, Resourcely stops the PR from being merged and (if applicable) routes the PR for approval.

We’ll dive into constructing some Guardrails to see them in action:

• Common use cases
• Building Guardrails via the UI or in code
• How Guardrails act during your deployment process

Common use cases

We built Guardrails to govern the configuration of cloud resources, without getting in the way of developers. Many of our customers suffer from issues like:

• Publicly accessible S3 buckets
• Overly permissive IAM
• Incorrect database versions
• Costly oversized infrastructure
• Accidental resource deletions causing downtime
• VM ingress rules open to all IP ranges

Guardrails can stop any of these configurations from ever making it into production. You can read more about why Resourcely Guardrails should be used in this announcement.

Constructing Guardrails

There are two options for writing Guardrails: a policy-as-code language called Really, or using the Resourcely UI.

Really

Really is a structured policy language that resembles SQL. Here’s an example of a Guardrail written with Really that requires IAM authentication to be enabled:

GUARDRAIL "Ensure AWS RDS database has IAM authentication enabled"
  WHEN aws_db_instance
    REQUIRE iam_database_authentication_enabled = true

You can see that this structured policy language is easy to read and write, especially when compared to existing policy-as-code like OPA/Rego. Guardrails follow this general 3-step structure as annotated below.

//Declaration
GUARDRAIL "Name of Guardrail"
  //Matcher
  WHEN cloud_resource_name
    //Requirements
    REQUIRE .....

There is an optional fourth component called OVERRIDE, that allows for routing failed Guardrails to the appropriate approvers for review.

Really supports a variety of operators and commands:

• Mathematical operators (=,≠,<,>,≤,≥)
• STARTS WITH, ENDS WITH
• MATCHES, MATCHES REGEX, MATCHES ANY, and MATCHES ANY REGEX
• IN, EXISTS, and, NOT
• Connectors (AND, OR)
• List operators (EVERY, SOME, and NO)
• HAS

See more Guardrail examples in the docs.

Quality of life

We’ve made the experience of writing policy-as-code much easier, with built-in autocomplete and a testing suite that allows you to make sure your Guardrails work as intended.

Autocomplete

Resourcely automatically indexes all cloud resources, their parameters, and options - for a seamless authoring experience.

Testing

Generate Terraform and test how your Guardrail will evaluate against various scenarios.

Build and Manage Guardrails in the UI

Users aren’t required to use code to write Guardrails. Resourcely Foundry supports the authoring of Guardrails using starter Guardrails:

When you choose a starter, users can configure the Guardrail using a UI like the below:

In this case, we choose which regions we want this Guardrail to enforce from a dropdown, choose an override approver, and then publish.

Once Guardrails are created, they can be searched, discovered, and managed through the Resourcely UI.

Guardrails during the deployment process

What good would policies for cloud infrastructure be, if they weren’t integrated into your CI and deployment pipeline?

Let’s say you have a Guardrail that limits AWS instance types to a series machines:

GUARDRAIL "[EC2] Allowed EC2 instance types"
  WHEN aws_instance
    REQUIRE instance_type STARTS WITH "a"
  OVERRIDE WITH APPROVAL @InfraOps

When used standalone or in combination with Blueprints, Guardrails are a check as part of your CI pipeline. Let’s say that a developer tries to submit a PR where an aws_instance has an instance_type that doesn’t start with a (thus violating the Guardrail). Here’s what happens when we submit a PR with an instance_type that starts with c.

Resourcely stopped this Guardrail from being merged.

When Guardrails are attached to Blueprints, they provide guidelines and instant feedback to developers who are configuring infrastructure. A Blueprint for deploying EC2 would be limited to what the Guardrail allows only.

The Guardrail lock is exposed in the Blueprint form, which would enable the developer to unlock the field and choose a different instance type.

If this were to happen, the OVERRIDE will fail the PR checks and route to the InfraOps team for approval.

Guardrails are scalable policy-as-code

Keeping your infrastructure secure and stable without disrupting your developers can be challenging, especially with existing tooling like Rego/OPA. Resourcely Guardrails help companies build secure defaults and govern their cloud resources as they scale with easy-to-write and maintainable policies.

You can get started with Resourcely today, even if you only want to use Guardrails. Sign up to get access here!

‍