diff --git a/tech_docs/Jinja2_guide.md b/tech_docs/Jinja2_guide.md index bbff87b..809e7f3 100644 --- a/tech_docs/Jinja2_guide.md +++ b/tech_docs/Jinja2_guide.md @@ -211,4 +211,192 @@ network-automation/ └── outputs/ # Rendered configs ``` -**Key Takeaway:** Jinja2 turns network configs from **manual CLI work** into **version-controlled code**. The more you template now, the more time you save later. \ No newline at end of file +**Key Takeaway:** Jinja2 turns network configs from **manual CLI work** into **version-controlled code**. The more you template now, the more time you save later. + +--- + +Great pivot! **Rego** (Open Policy Agent’s policy language) and **Jinja2** serve different but complementary roles in infrastructure automation. Let’s break down how they compare, overlap, and where you’d use each—with gritty examples tailored to infrastructure/security use cases. + +--- + +### **1. Quick Comparison: Jinja2 vs. Rego** +| Feature | Jinja2 | Rego | +|---------|--------|------| +| **Primary Use** | Templating (generate configs/docs) | Policy enforcement (validate inputs) | +| **Input** | YAML/JSON/CSV | JSON/YAML (often from APIs) | +| **Output** | Rendered text (configs, CLI commands) | Policy decisions (allow/deny + detailed reasons) | +| **Context** | "Generate this network config" | "Is this network config compliant?" | +| **Key Strength** | Flexibility in text generation | Logic-based evaluation with auditing | + +--- + +### **2. Where Jinja2 and Rego Overlap** +Both operate on structured data (YAML/JSON), but solve different problems in the pipeline: + +#### **Example Workflow: Network Change Automation** +1. **Jinja2**: Generates a candidate BGP config from YAML variables. + ```jinja + router bgp {{ bgp.asn }} + neighbor {{ neighbor.ip }} remote-as {{ neighbor.asn }} + ``` +2. **Rego**: Validates the generated config *before* deployment. + ```rego + # Prevent BGP peers in untrusted ASNs + deny[msg] { + input.kind == "bgp_config" + not input.neighbor.asn in trusted_asns + msg := sprintf("BGP peer ASN %v is not trusted", [input.neighbor.asn]) + } + ``` + +--- + +### **3. Rego Use Cases (Where It Shines Over Jinja2)** +#### **A. Pre-Deployment Validation** +**Problem**: Ensure Jinja2-generated configs meet security/compliance rules. +**Rego Policy** (`policies/networking.rego`): +```rego +package networking + +# Deny firewall rules that allow SSH from the internet +deny[msg] { + input.kind == "firewall_rule" + input.action == "allow" + input.port == 22 + input.source == "0.0.0.0/0" + msg := "SSH must not be open to the internet!" +} + +# Require VLAN descriptions for auditability +deny[msg] { + input.kind == "vlan_config" + not input.description + msg := "VLANs must have a description" +} +``` + +**How to Use**: +```bash +# Validate a Jinja2-rendered config against Rego +opa eval --data policies/networking.rego --input rendered_config.json "data.networking.deny" +``` + +--- + +#### **B. Multi-Cloud Policy Enforcement** +**Problem**: Enforce tagging standards across AWS/Azure/GCP. +**Rego Policy** (`policies/cloud.rego`): +```rego +package cloud + +# Require 'CostCenter' tag on all resources +deny[msg] { + input.resource.tags["CostCenter"] == "" + msg := "All resources must have a CostCenter tag" +} + +# Block public S3 buckets +deny[msg] { + input.kind == "aws_s3_bucket" + input.acl == "public-read" + msg := "Public S3 buckets are prohibited" +} +``` + +**Input (JSON from Terraform/Cloud API)**: +```json +{ + "kind": "aws_s3_bucket", + "acl": "public-read", + "tags": { "CostCenter": "" } +} +``` + +**Output**: +```json +{ + "deny": [ + "All resources must have a CostCenter tag", + "Public S3 buckets are prohibited" + ] +} +``` + +--- + +#### **C. Network Topology Auditing** +**Problem**: Validate that Jinja2-generated network designs follow best practices. +**Rego Policy** (`policies/topology.rego`): +```rego +package topology + +# Core switches must have redundant links +deny[msg] { + input.device.role == "core" + count(input.device.links) < 2 + msg := "Core devices must have redundant links" +} + +# VLAN 1 should not be used (security best practice) +deny[msg] { + input.vlan.id == 1 + msg := "VLAN 1 is prohibited for security reasons" +} +``` + +--- + +### **4. When to Use Jinja2 vs. Rego** +| Scenario | Tool | Why | +|----------|------|-----| +| Generating Cisco/Juniper configs | Jinja2 | Best at text templating. | +| Validating configs pre-deploy | Rego | Logic-based policy checks. | +| Creating API payloads | Jinja2 | Structure dynamic JSON/YAML. | +| Auditing existing infra | Rego | Query live state for violations. | +| Documenting network designs | Jinja2 | Render Markdown/HTML. | +| Enforcing security rules | Rego | Evaluate against compliance rules. | + +--- + +### **5. Pro Tips for Rego in Infrastructure** +1. **Test Policies Early**: Use `opa test` to unit test your Rego rules. + ```bash + opa test policies/ -v + ``` +2. **Integrate with CI/CD**: + ```yaml + # GitLab CI example + validate_policy: + image: openpolicyagent/opa + script: + - opa eval --data policies/ --input $CHANGES "data.deny" + ``` +3. **Debug with `trace`**: + ```rego + # Add to your policy to see evaluation steps + trace(sprintf("Input: %v", [input])) + ``` + +--- + +### **6. Example End-to-End Flow** +1. **Jinja2 Generates Config**: + ```bash + jinja2 bgp_template.j2 vars.yml > bgp_config.json + ``` +2. **Rego Validates It**: + ```bash + opa eval --data policies/ --input bgp_config.json "data.networking.deny" + ``` +3. **Only deploy if Rego returns no denials**. + +--- + +### **7. Key Takeaway** +- **Jinja2**: Your "build" tool (creates configs/scripts/docs). +- **Rego**: Your "guardrail" tool (ensures compliance/safety). + +Together, they form a **powerful pipeline**: +`Jinja2 (generate) → Rego (validate) → Ansible/Terraform (deploy)` + +Want a deep dive on a specific Rego use case (e.g., network security policies or cloud governance)? I can break it down with real code. \ No newline at end of file