Rule Engine Architecture

How Rules Work Inside TFGaurd

Ever wondered what happens between uploading your Terraform file and getting a security report? This page is your beginner-friendly, visual guide to understanding how rules work inside our policy engine — no programming experience required.

1,200+ Security Rules

4 Cloud Providers

< 2s Scan Duration

100% Local & Private

What Exactly Is a "Rule"?

Think of rules as automated inspectors. They check every piece of your cloud configuration against security best practices — instantly.

Building Inspector

Before a building is approved, an inspector checks electrical wiring, fire exits, and structural integrity. TFGaurd rules do the same for your cloud — they inspect every resource before it goes live.

Spell Checker

Your word processor underlines mistakes as you type. TFGaurd does the same — it highlights misconfigurations in real time, so you fix them before deploying.

Pre-Flight Checklist

Pilots run checklists before every takeoff. Each rule in TFGaurd is one item on a 1,200-point pre-flight checklist for your cloud infrastructure.

In plain English: A rule is a simple question like "Is this database encrypted?" or "Is this storage bucket publicly accessible?". TFGaurd asks 1,200+ such questions automatically every time you scan.

The Rule Processing Pipeline — At a Glance

Here's the high-level journey your Terraform code takes through TFGaurd's internal rule processing engine.

1. Input

Upload your .tf files or plan JSON

2. Parse

Engine reads & breaks down every resource

3. Map

Build an in-memory resource graph

4. Evaluate

Run 1,200+ rules against every resource

5. Report

Generate pass/fail verdict + remediation

Deep Dive: How Rules Work Step by Step

Let's walk through each stage of internal rule processing in detail, with code examples and real-world context.

1
Input — Your Terraform Code

Everything begins with your infrastructure code. In Terraform, you define cloud resources — servers, databases, storage buckets, networks — inside .tf files written in HCL (HashiCorp Configuration Language).

When you run terraform plan, Terraform computes the exact set of changes that will happen in your cloud. TFGaurd can scan both raw HCL source files and the more precise plan JSON output.

                HCL — Example Input
# A simple AWS S3 bucket definition
resource "aws_s3_bucket" "user_data" {
  bucket = "my-production-data"
  acl    = "public-read"  # ⚠ This is dangerous!

  tags = {
    Environment = "production"
  }
}

Real-world analogy: This step is like handing your building blueprints to the inspector. The blueprints describe what you plan to build — the inspector hasn't started checking yet.

2
Parsing — Breaking Down the Code

The parser is the first internal component that touches your code. It reads the raw text and converts it into a structured data format (like a spreadsheet of resources) that the rule engine can work with.

Here's what the parser extracts from each resource:

Resource Type — e.g. aws_s3_bucket, azure_storage_account
Resource Name — your label for it, like user_data
All Attributes — every setting: encryption, access level, tags, region, etc.
Provider — which cloud this belongs to (AWS, GCP, Azure, Oracle)
Planned Action — create, update, or delete

                JSON — Parsed Output
{
  "type":          "aws_s3_bucket",
  "name":          "user_data",
  "provider":      "registry.terraform.io/hashicorp/aws",
  "action":        "create",
  "attributes": {
    "bucket":   "my-production-data",
    "acl":      "public-read",
    "tags": { "Environment": "production" }
  }
}

Why parsing matters: The raw code is human-readable text. The parsed output is machine-readable data. Rules can't understand text — they need structured data to make decisions.

3
Resource Graph — Mapping Everything

After parsing, TFGaurd constructs an in-memory resource graph. Think of this as a detailed map connecting all your cloud resources together. Each resource becomes a "node" on this map, with its attributes and relationships.

Why do we need a graph? Because cloud resources don't exist in isolation:

A security group is attached to a server
A database resides inside a VPC network
An IAM role grants permissions to a Lambda function

The resource graph lets rules understand the context of each resource — not just its individual settings, but how it relates to everything else.

Analogy: Imagine a city map. Each building (resource) has an address and features, but the map also shows roads connecting them. TFGaurd's resource graph is this city map for your cloud — it sees both individual buildings and their connections.

4
Rule Evaluation — The Core Engine

This is where the magic happens. The rule engine — the heart of TFGaurd's rules system architecture — now runs every applicable rule against the resource graph.

How a single rule works internally:

Match: The engine checks the resource type. An S3 bucket rule only runs on aws_s3_bucket resources — it ignores databases, servers, and everything else.
Inspect: The rule reads the specific attribute it cares about. For example, a "public access" rule reads the acl attribute.
Decide: The rule applies its policy logic: "Is acl set to public-read? If yes → VIOLATION."
Report: If a violation is found, the rule outputs the severity, explanation, and exact fix.

                Python — Simplified Rule
# This is a simplified version of an actual TFGaurd rule
def check_s3_not_public(resource):
    """S3 bucket must not allow public access"""
    acl = resource.get("acl", "private")

    if acl in ["public-read", "public-read-write"]:
        return {
            "passed":   False,
            "severity": "CRITICAL",
            "message":  "S3 bucket has a public ACL",
            "fix":      "Set acl = 'private'"
        }

    return {"passed": True}

TFGaurd's rule registry organizes rules by resource type. When an aws_s3_bucket is found, the engine looks up all S3 rules and runs them in sequence. This process repeats for every resource in your configuration.

Performance: Despite having 1,200+ rules, the engine completes full evaluations in under 2 seconds. Rules are indexed by resource type, so only relevant rules execute for each resource.

5
Verdict & Report — Actionable Results

After all rules have executed, TFGaurd aggregates the results into a clear, actionable security report. Every violation includes everything you need to fix it:

Severity Level — CRITICAL, HIGH, MEDIUM, or LOW
Resource Address — Exactly which resource failed (e.g. aws_s3_bucket.user_data)
Human-Readable Explanation — What the problem is, in plain English
Exact Remediation — The specific code change to fix it

                Output — Scan Results
✓ Parsed 18 resources from plan file
✓ Evaluated 342 rules across 4 providers

[CRITICAL] aws_s3_bucket.user_data
  S3 bucket has a public ACL (public-read)
  Fix: Set acl = "private"

[HIGH] aws_db_instance.production
  RDS instance does not have encryption at rest
  Fix: Set storage_encrypted = true

[MEDIUM] aws_instance.web_server
  EC2 instance missing detailed monitoring
  Fix: Set monitoring = true

━━━ Scan complete: 3 violations (1 critical, 1 high, 1 medium) ━━━

Final analogy: The security report is like getting your building inspection results. It tells you exactly what passed, what failed, and precisely what to fix — so you can get approved and go live with confidence.

Types of Rules in TFGaurd

Rules aren't one-size-fits-all. Our rules system architecture supports multiple categories, each designed for different security concerns.

Encryption Rules

Verify that storage, databases, and data-in-transit are always encrypted using industry-standard algorithms (AES-256, KMS).

Network Access Rules

Ensure security groups, firewalls, and network ACLs don't expose ports like SSH (22) or RDP (3389) to the public internet.

IAM & Permission Rules

Detect overly permissive IAM policies — like wildcard (*) permissions — that could give attackers unlimited access.

Logging & Monitoring Rules

Verify CloudTrail, Flow Logs, and access logging are enabled. You can't protect what you can't see.

Tagging & Compliance Rules

Enforce mandatory tags (Environment, Owner, CostCenter) to maintain governance and billing visibility.

Custom Rules

Create your own rules via the web dashboard — specify the resource type, attribute, condition, and severity. No code needed.

Frequently Asked Questions

Common questions about how rules work inside TFGaurd.

Do rules run in the cloud or on my machine?

100% local. TFGaurd runs entirely on your machine or CI runner. Your Terraform code and plans never leave your environment. There's no SaaS middleman, no cloud upload, and no data persistence outside your control.

Can I create my own custom rules?

Yes! TFGaurd supports custom rules via the web dashboard. You specify the resource type, the attribute to check, the condition (equals, not equals, contains, etc.), the expected value, and the severity. No programming required — these custom rules run alongside the built-in 1,200+ rules.

How fast is the rule engine?

The entire evaluation process — parsing, graph construction, rule execution, and report generation — completes in under 2 seconds for typical configurations. Rules are indexed by resource type, so only relevant rules run for each resource, keeping things blazing fast.

Which cloud providers are supported?

TFGaurd includes built-in rules for AWS, Google Cloud Platform (GCP), Microsoft Azure, and Oracle Cloud Infrastructure (OCI). AWS rules are available in the free tier; GCP, Azure, and Oracle rules are included in the premium plan.

What's the difference between scanning HCL and scanning a plan file?

HCL scanning reads your raw source code — it catches ~80% of issues. Plan-file scanning reads the resolved output of terraform plan, where all variables, modules, and conditions are already evaluated. This catches ~98% of issues, including problems hidden behind dynamic values.

See the Rule Engine in Action

Upload your first Terraform file and watch TFGaurd evaluate 1,200+ security rules in under 2 seconds — completely free.

Start Scanning Free