Infrastructure as code and policy as code

Not long ago, setting up infrastructure meant clicking through consoles or running commands by hand. Nobody could say for certain how a server had been configured, and two “identical” environments rarely were. Infrastructure as code (IaC) replaced this with files that describe the desired infrastructure: networks, virtual machines, storage buckets, firewall rules and permissions. A tool reads the files and makes reality match them.

Two common IaC tools

Both are declarative: you describe what should exist, and the tool works out the steps. Both also let you preview changes before applying them, which is where security reviews fit naturally.

Why IaC is a security opportunity

• Every change is visible in version control, with an author, a review and a history.
• The same reviewed template produces the same environment every time, removing hand-made differences.
• Mistakes can be caught automatically before anything is deployed, which is the heart of shifting left.
• Recovery is faster: a damaged environment can be rebuilt from known-good code.

It is also a risk. A single insecure template, such as a storage bucket open to the public or a firewall rule allowing the whole internet in, is copied into every environment built from it. And IaC files, state files and pipeline variables can contain secrets or reveal the layout of your infrastructure, so they need the same protection as source code.

Policy as code

Policy as code means writing security rules in a machine-readable form so a tool can check them automatically. Instead of a document saying “storage must never be public”, you have a rule that fails the pipeline when a template makes storage public. Open Policy Agent (OPA), a graduated project of the Cloud Native Computing Foundation, is a general-purpose policy engine with its own policy language, Rego, used for IaC checks, Kubernetes admission control and more. Scanners such as Checkov come with many ready-made checks for Terraform, CloudFormation and Kubernetes files.

Where to run the checks

1. In the editor, so developers see problems while writing.
2. In the pull request, blocking merge on high-severity rule violations.
3. On the planned change, just before it is applied.
4. At deploy time in the platform, for example Kubernetes admission control, as a last gate.
5. Continuously against the live environment, because not every change goes through code. That is the subject of the next lesson.

Where FireAI fits

FireAI works on a single Mac rather than in cloud infrastructure, but it shares one habit with IaC: configuration you can keep as a file. Its rules can be exported to back them up or move them to another Mac, and imported back in safely.