Published on

Rules as code

‘No public storage’, ‘everything encrypted’, ‘nothing without cost tags’. If these rules exist only in a document, they get broken. If they exist in code, they are checked on every change, before it is applied.

Service line Automation and IaC

The standard nobody reads

Almost every organisation has a security or infrastructure standard: a document with reasonable rules. Almost every one also has resources that break it. Not out of bad faith, but because whoever writes the change does not have the standard in front of them at that moment, and whoever reviews it cannot check thirty rules by eye on every change.

From document to check

The standard is checked on every changeA gate of five rules: two broken blocking rules stop the change.IAC · RULES AS CODEThe standard is checked on every changeChangeplan calculatedRULES GATENo public storagefails on: store.reportsEverything encryptedOwner, application and environment tagsfails on: 3 resourcesPermitted regions onlyNo administration port openChange stopped: 2 blocking rules broken.The message says which rule, which resource and why.Exceptions are possible, but written down: owner, reason and review date.Illustrative exampleN100F · n100f.com

The alternative is to write the rules as code that runs against every plan before it is applied:

  • 'No data storage may be public.'
  • 'All disks and databases are encrypted.'
  • 'Every resource carries owner, application and environment tags' (the ones cost allocation needs).
  • 'Only these regions are permitted.'
  • 'No administration port open to the internet.'

If the plan breaks any of them, the change stops with a message saying which rule, on which resource and why.

Severity levels

Not all rules carry the same weight:

  • Blocking: the change is not applied (exposed data, encryption switched off).
  • Warnings: it is applied, but recorded and reviewed by somebody (an optional tag missing).

And for exceptional cases, documented exceptions: with an owner, a reason and a review date, never silent (the same logic as in reviewing without slowing down).

Why it works

The standard stops depending on the memory of whoever writes and the attention of whoever reviews. It is met every time, in every environment, on every change. And because the rule is written in one place, improving it improves every review at once.

Rules protect what gets built from code. What remains is whatever existed before it.


How we apply it: Automation and IaC.

If your cloud cost keeps growing and nobody knows why, or your architecture depends on whoever built it, let’s talk.

Let’s talk