Published on

Baselines: the server it should be

Creating a server with code is half the job. The other half is that, months later, it is still configured as defined: packages, users, access, patches. That is written as a baseline and checked regularly.

Service line Automation and IaC

Created alike, aged differently

Ten servers created with the same code are born identical. Six months later they are not: one had a tool installed to diagnose a problem, another did not get the latest patch, on a third somebody created a temporary user that was never deleted.

Infrastructure as code solves how a server is born. What happens during its life needs another tool: configuration management, guided by a baseline.

What a baseline is

A baseline is the written description of how a type of server should be configured:

  • System and patches: the expected version and update level.
  • Packages: what must be installed and what must not.
  • Users and access: who can log in and how (for example, by key only, never by password).
  • Services: what must be running and what must be switched off.
  • Hardening: the system's security settings.
  • Logging and monitoring: that it sends its logs and metrics where it should.

Six servers, eight controlsA baseline compliance matrix by server and control, with a percentage per server.IAC · BASELINESSix servers, eight controlsPatchesPackagesUsersKeysServicesHarden.LogsMetricsweb-01100 %web-02100 %web-0388 %db-01100 %db-0275 %adm-01100 %A periodic report, changing nothing: dated, stored and comparable with the previous one.db-02 fails two controls: a user too manyand a reverted hardening setting. It is fixed or justified.Example reportN100F · n100f.com

Apply and check, not just apply

The baseline is used in two ways:

  1. To apply: a tool brings each server to the described configuration, repeatably (as in declare, do not order).
  2. To check: regularly, the same tool reviews each server without changing anything and produces a report of what complies and what does not.

That periodic report, dated and stored, is extremely valuable: it shows how each server has evolved, serves as evidence in an audit and lets you see at a glance which machines need attention.

One baseline per type, not per machine

You do not write a baseline for every server, but for every type: web server, database server, administration workstation. Each machine declares its type and inherits its baseline.

Checking each server regularly against its baseline leads to the broader question: what to do when reality moves away from the code?


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