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.
Apply and check, not just apply
The baseline is used in two ways:
- To apply: a tool brings each server to the described configuration, repeatably (as in declare, do not order).
- 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.