DEV Community: StackGuardian

3 Terraform policies to start with: tags, ingress, instance types

Diana Loomis — Wed, 14 Oct 2026 11:03:01 +0000

Most teams agree they need guardrails on Terraform changes. Fewer agree on which policy to write first. Here are three starter checks you can run with Tirith, the open-source policy engine from StackGuardian, against the JSON plan your pipeline already produces.

Install Tirith

Tirith needs Python 3.8 or newer. Install it from the pinned Git tag:

pip install "git+https://github.com/StackGuardian/tirith.git@1.2.1"

Note: Tirith is not on PyPI. pip install tirith installs an unrelated project.

The three policies

Environment tag. Every resource must carry an Environment tag set to dev, staging or prod. A resource with no tag fails instead of slipping through.

No public ingress. No inline ingress rule on an aws_security_group may allow 0.0.0.0/0. Rules defined as separate resources need their own check.

Approved instance types. Every aws_instance must use a type from your allowlist. One oversized instance fails the check.

All three fit in one policy file, starter.json:

{
  "meta": {
    "version": "v1",
    "required_provider": "stackguardian/terraform_plan",
    "id": "starter-guardrails",
    "name": "Starter guardrails"
  },
  "evaluators": [
    {
      "id": "environment_tag_is_valid",
      "provider_args": {
        "operation_type": "attribute",
        "terraform_resource_type": "*",
        "terraform_resource_attribute": "tags.Environment"
      },
      "condition": { "type": "RegexMatch", "value": "^(dev|staging|prod)$" }
    },
    {
      "id": "no_public_cidr_in_ingress",
      "provider_args": {
        "operation_type": "attribute",
        "terraform_resource_type": "aws_security_group",
        "terraform_resource_attribute": "ingress.*.cidr_blocks"
      },
      "condition": { "type": "NotContains", "value": "0.0.0.0/0" }
    },
    {
      "id": "instance_type_is_approved",
      "provider_args": {
        "operation_type": "attribute",
        "terraform_resource_type": "aws_instance",
        "terraform_resource_attribute": "instance_type"
      },
      "condition": { "type": "ContainedIn", "value": ["t3.micro", "t3.small", "t3.medium"] }
    }
  ],
  "eval_expression": "environment_tag_is_valid && no_public_cidr_in_ingress && instance_type_is_approved"
}

Run it against your plan

terraform plan -out=tfplan -input=false
terraform show -json tfplan > plan.json
tirith lint starter.json
tirith --fail-on-error -policy-path starter.json -input-path plan.json

tirith lint catches policy mistakes before they reach CI. With --fail-on-error, a failing policy exits with code 3 and fails the pipeline step. Without that flag, Tirith exits 0 even when a check fails.

Each result names the resource and attribute (output trimmed):

Check: environment_tag_is_valid
  FAILED
    2. FAILED: [aws_instance.batch (create)] tags.Environment: `"production"` does not match regex pattern `"^(dev|staging|prod)$"`

Check: no_public_cidr_in_ingress
  FAILED
    2. FAILED: [aws_security_group.web (create)] ingress.1.cidr_blocks: Found `"0.0.0.0/0"` inside `["0.0.0.0/0"]`

Check: instance_type_is_approved
  FAILED
    2. FAILED: [aws_instance.batch (create)] instance_type: Failed to find `"m5.24xlarge"` inside `["t3.medium", "t3.micro", "t3.small"]`

Passed: 0 Failed: 3 Skipped: 0
✘ Failed final evaluation

Warning: With "*", resources that can't take tags, such as aws_iam_role_policy_attachment, also fail. Adding "error_tolerance": 2 to the condition stops those failures, but it also lets a taggable resource with no Environment tag pass. If that trade-off doesn't suit you, add one evaluator per resource type instead.

Wrapping up

Start with these three, see what they catch on real pull requests, then extend from the policy cookbook. To try Tirith on your own plans:

StackGuardian / tirith

Plug IaC governance into any IaC pipeline. Evaluate plans with Tirith, protect sensitive values, enforce centralised policies, and surface actionable results before infrastructure changes are applied.

Tirith — IaC Governance plugin

Note

New — tirith ui, an interactive interface. In beta, and we want your input.

Explore a failing evaluation down to the resource that caused it, assemble policies from a form, and experiment in a playground with worked examples. Try it with pip install 'py-tirith[tui] @ git+https://github.com/StackGuardian/tirith.git', then tirith ui — see The interactive interface.

It is new, so the rough edges are still being found. Tell us what is confusing, what is missing, or what you would rather it did open an issue or say so in Slack Nothing about the existing CLI changes: same flags, same --json output, same exit codes.

Plugin IaC Governance for any pipeline, running anywhere. Evaluate plans with Tirith, protect sensitive values, enforce centralised governance, and surface actionable results before infrastructure changes are applied.

Tirith reads the plan your pipeline already produces — the output…

View on GitHub

Checkov and Tirith: Governing Your Own Rules in Every IaC Pipeline

Diana Loomis — Fri, 09 Oct 2026 15:59:51 +0000

Your pipeline already runs Checkov, and the scan passes. An encrypted, private bucket can still be missing the owner tag your incident process depends on, and a valid plan can still go over the monthly cost limit finance agreed to. Checkov checks that resources are secure. Rules like these come from how your organization operates, so they need their own owner and a way to be enforced.

The rules that come from your organization

Most platform teams need to know who owns each resource, whether a change fits the budget, and whether every repository enforces the same version of a rule.

That last one is where things slip. A team can run the right checks in one repository while another repository runs a copy of the policy that was last updated a year ago.

Writing those rules as Tirith policies

Tirith is StackGuardian's open-source policy engine. It runs as an additional step in the pipeline you already have, so Checkov and your other checks keep running as they are.

A Tirith policy is declarative JSON with one consistent structure: you choose a provider, select the value or operation, then state the condition. Providers exist for Terraform plans, Infracost estimates, Kubernetes manifests and workflow files, so an owner-tag rule and a cost rule are written the same way, and reviewers read them the same way.

To connect a pipeline, you add one step after terraform plan: the Tirith GitHub Action, the Tirith GitLab CI/CD component or a Tirith step in Bitbucket Pipelines. Your apply jobs stay where they are.

To install Tirith, use the pinned release from GitHub:

pip install "git+https://github.com/StackGuardian/tirith.git@1.2.1"
tirith --version

Warning: pip install tirith installs a different, unrelated package with the same name on PyPI.

Keeping every pipeline on the same policy

Every route works in local mode first, evaluating the policy files committed to the repository. Copy the same file into fifty repositories, though, and over time you have fifty versions. Platform mode is optional: the same step evaluates plans against the policies your StackGuardian organization enforces, so policy owners change a rule once and every connected pipeline picks it up on its next run.

Depending on your plan and setup, StackGuardian can also run Tirith and Checkov on your plans, keep every result linked to the run that produced it for audit, and report the pipelines that skip the checks.

Wrapping up

Start with a rule your engineers still check by hand and try it in one pipeline. The full guide has a minimal owner-tag policy and the exact plan, check, apply sequence. It also covers what reviewers see in each CI system when a policy fails, how a finding becomes a reviewed and tested Tirith policy, and which features are in Tirith 1.2.1 and which are still in development.

Read the full guide: Checkov and Tirith: Governing Every IaC Pipeline With StackGuardian

Meet Tirith, StackGuardian's Open-Source Policy Engine

Diana Loomis — Mon, 05 Oct 2026 09:13:31 +0000

Tirith (GitHub: https://github.com/StackGuardian/tirith) is StackGuardian's open-source policy as code framework. It reads the JSON your pipeline already produces, such as the output of terraform show -json, and checks it against policies stored as JSON files. Each rule passes, fails, or is skipped, and the result names the resource and value behind it. Tirith is licensed under Apache 2.0, needs no account, and runs on your own machine or CI runner.

Why Tirith?

There is no new policy language to learn. You pick a provider, an operation, and a condition such as Equals, ContainedIn, or RegexMatch, then combine checks with &&, ||, and !.

Built-in providers cover:

Terraform plans
Infracost cost estimates
Kubernetes manifests
StackGuardian workflow configurations
Any JSON document

That means one framework can block a public S3 bucket, cap EC2 spend at 100 USD a month, and require liveness probes on every pod.
Because policies live in your repository, the same files gate a GitHub Actions job, a GitLab pipeline, and a local run. With --fail-on-error, Tirith exits with code 3 on a violation, so a non-compliant change never reaches apply. Two recent additions help while you write policies:

tirith lint catches broken policies in pre-commit hooks.
tirith ui, currently in beta, is a terminal interface for exploring results and building policies.

Who is it for?

Tirith is for DevSecOps, platform, and cloud teams that need infrastructure guardrails without building their own policy engine. Tirith is also the engine behind StackGuardian's policy checks, and StackGuardian users can run tirith platform check to test a plan against their organization's central policies.

Get Started

Tirith is not on PyPI, so install it from GitHub:
pip install git+https://github.com/StackGuardian/tirith.git
Then evaluate a plan:
tirith -policy-path policy.json -input-path plan.json

Want to contribute?

The project welcomes new providers, evaluators, bug fixes, and pull request reviews. Read the contributing guide (https://github.com/StackGuardian/tirith/blob/main/CONTRIBUTING.md), open an issue to get one assigned. And if you have questions, drop them in the StackGuardian Slack community (https://join.slack.com/t/stackguardian-ol78820/shared_invite/zt-2ksag36j9-OjmXqQmyXudgYrV6FmesIQ).

A Guide to Getting Started with StackGuardian

Diana Loomis — Fri, 02 Oct 2026 12:23:09 +0000

If you run Terraform or OpenTofu across several teams, you know the pain: hand-built CI pipelines, credentials in pipeline variables, scattered state files, and compliance checks after deployment. StackGuardian is an infrastructure as code (IaC) automation and governance platform that brings execution, credentials, state, and policy as code into one place, so every infrastructure change follows one trusted standard.

What you need

A StackGuardian account, a Git repo with a small Terraform project, an AWS, Azure, or GCP sandbox, and permission to create an IAM role or equivalent. For GitHub, you also need organization admin rights to install the StackGuardian GitHub App.

Connect Git and your cloud

On first sign-in, choose GitOps for IaC and name your organization. If you signed up with GitHub, onboarding asks you to install the GitHub App, which becomes your first VCS connector, so don't create it again. Instead of projects, StackGuardian organizes workflows into Workflow Groups, usually mapped to environments or teams. Connect GitHub, GitLab, Bitbucket, or Azure DevOps to trigger runs on pull requests, pushes, or tags. For AWS, use OIDC federation: runs get temporary credentials, and no long-lived secrets are stored. Azure and GCP have their own connectors.

Create a workflow

In a Workflow Group, create a Terraform or OpenTofu workflow pointing to your repo, branch, and working directory. Add parameters, and reference secrets from the StackGuardian vault or a supported external vault so they never appear in your configuration. Select your cloud connector, keep the managed backend on for versioned state, and enable approvals. Use a private runner if executions must stay in an environment you control. Beyond built-in types like Ansible, Kubernetes, and CloudFormation, custom workflows bring any toolset onto the platform.

Plan, review, apply

Click Create Run. StackGuardian plans, evaluates policies, and pauses for approval. The summary shows resource changes and Infracost estimates, using a built-in key or your own. Approve, and the apply runs.

Add a guardrail

Policies use Tirith, StackGuardian's open-source policy as code framework, and you can bring existing Open Policy Agent (OPA) and Checkov policies (see supported policy types). Start from 250+ marketplace templates or a no-code builder. For example, a rule allowing only t3.micro for aws_instance stops non-compliant plans before they reach your cloud.

Where to go next

Add PR-triggered plans and Stacks for multi-layer infrastructure. To catch changes made outside Terraform, ask the StackGuardian team to enable drift detection. For resources never written as code, SGCode discovers them and generates code for review, then opens a pull request and runs a plan. The managed runtime supports Terraform up to 1.5.7; for newer versions, use OpenTofu or a custom runtime image.
Check out https://www.stackguardian.io/ for more details.