Customizing your configuration with context

How using context and Guardrails can help you build bespoke configuration workflows

AUTHOR

Chris Reuter

PUBLISH DATE

October 2, 2024

Configuring and deploying cloud infrastructure is not consistent across organizations or teams. While it may seem straightforward to build a preferred deployment pattern for your developers, you will quickly learn that the context of an application’s use case makes a world of difference.

Geography & location: would you treat infrastructure in the EU and the US differently?
Data privacy: should PII get the same treatment as public data?
Environment: should you use different infrastructure in prod vs test?

We built Resourcely to be a highly modular experience that could be used to customize workflows for developers while providing the least amount of friction. You can use Resourcely’s Context and Guardrails to structure rules that are highly dependent on the unique situation a developer is facing: reducing back and forth and preserving the stability, security, and compliance of the infrastructure that is being used.

You can follow along with the video version of this blog here if you prefer that medium!

What is Context?

Context in the context (ha) of Resourcely are information about cloud infrastructure that can be collected from developers are the time of configuration. You can define global context that is collected across some group of Blueprints, or create individual context questions at the individual Blueprint level.

Collecting context can be very useful for applications outside of Resourcely: tracking costs, ownership, regions, and more.

Context can also be very useful for customizing cloud resource creation (with Blueprints) and governance (with Guardrails). Consider a FinOps team that is interested in reducing costs. One great example is to minimize infrastructure sizing by restricting instance types (using only small sizes), GPU usage, storage type (preferring HDD to SSD), and more.

Let’s look at how to use context in Resourcely to enforce these rules.

Applying Context

To use context, you must first collect context and associate it with a Blueprint. You can do so by navigating to the global context menu in Resourcely.

After you have created context questions, they will appear in your Blueprint:

These context values can be referenced within Guardrails. This gives you two things:

Blueprint forms will have relevant Guardrails attached, based on the context question.
Guardrails will be evaluated after the Terraform plan is created, but before it is applied.

Consider the following Guardrail:


GUARDRAIL "If context = foo then add a Datadog monitor"
  WHEN aws_instance AND CONTEXT identifier = "foo"
    REQUIRE cpu_options.threads_per_core > 2

For Blueprints that create an aws_instance, this Guardrail will appear on the threads_per_core argument. Here is what a form would look like that didn’t violate this guardrail (identifier <> “foo”):

…while here is a Blueprint form that does violate this Guardrail (identifier = “foo”):

This contextual Guardrail is also evaluated as part of a CI process, evaluated after the Terraform plan is generated, and blocked if the Guardrail is violated:

Example: Context for RDS

Consider a scenario where you are a multinational company organized in two business units (BUs): a US-based BU, and an international BU. You want to give developers the ability to create their own RDS instances securely, but you want to enforce the following rules:

You have had issues where databases were undersized for production, so you want to make sure that production instances have > 10 GB of storage.
You are sensitive to cost, and your FinOps team wants to restrict instance sizes to smaller than Large sizes regardless of the series.
All production use cases across BU, as well as test use cases in the US only, should use mySQL. Non-US test instances should use postgres.

These three Guardrails would enforce this criteria:


GUARDRAIL "When context prod"
  WHEN aws_db_instance AND CONTEXT env = "prod"
    REQUIRE allocated_storage > 10
  OVERRIDE WITH APPROVAL @default
    
GUARDRAIL "Prevent large RDS instances in test"
  WHEN aws_db_instance AND CONTEXT env = "test"
    REQUIRE instance_class NOT MATCHES "*large*"
  OVERRIDE WITH APPROVAL @FinOps

GUARDRAIL "[RDS] Engine types"
  WHEN aws_db_instance AND CONTEXT env = "prod" OR aws_db_instance AND CONTEXT loc = "us"
    REQUIRE engine IN ["mysql"]
  WHEN aws_db_instance AND CONTEXT loc = "non-us"
    REQUIRE engine IN ["postgres"]
  OVERRIDE WITH APPROVAL @default

‍Blueprint form behavior

Without any context selected, these Guardrails are not being violated and no restrictions are placed on the Blueprint form.

After selecting some context:

…Guardrail feedback is placed on our form. We have selected MariaDB as an exception to our Guardrail below by unlocking the Guardrail.

We submit the form and a PR is automatically created with our context questions included.

We can see that because we violated a Guardrail by selecting MariaDB, merging is blocked and an approval is requested.

With context built into Guardrails, we have accomplished a few things:

built custom workflows for developers based on their unique situation
provided feedback early in the configuration process
this PR was blocked because it violated an explicit rule. PRs that don’t violate our Guardrails will pass, and the relevant team won’t need to waste time reviewing it.

Example: Context for S3

Let’s look at another example, this time around data encryption. Suppose that we want to require that all s3 buckets with public data in them have AES256 encryption. The AWS aws_s3_bucket_server_side_encryption_configuration resource has a property called sse_algorithm that has three possible options: aws:kms, aws:kms:dsse, and AES256. Resourcely Blueprints would normally expose these 3 options to developers

After selecting that our data was “confidential” from our context dropdown, the Guardrail is applied and the developer is directed towards our standard.

If they violate the Guardrail (or submit Terraform outside of Resourcely), the Guardrail will evaluate and block merging in our change management tooling with our context displayed:

and the Guardrail referenced in-line with code.

Conclusion

Context in Resourcely is a powerful tool for collecting information, customizing the developer experience, and enforcing Guardrails based on various scenarios.

You can create an infinite number of Guardrails because you can create and collect as much context as you would like! The best part of Guardrails is that they can simply be a governance layer as part of your CI, so that teams who would benefit can seamlessly integrate into development workflows: