Cybersecurity glossary
What is Immutable Infrastructure?
Learn what immutable infrastructure is, how golden images and cattle-not-pets reduce drift, and why SSH hotfixes recreate the snowflake servers you were trying to leave.
Definition
Immutable infrastructure is the practice of never changing running servers or containers in place: new versions are built as images or artifacts, deployed as replacements, and old instances are destroyed so production matches a known, versioned build rather than a history of SSH patches.
Why immutable infrastructure matters
A server that has been patched by three people, two Ansible runs, and a “temporary” iptables rule cannot be reproduced after a crash. Attackers love that opacity; so do 3 a.m. outages.
Immutable infrastructure makes the running fleet a projection of versioned images. If it is wrong, you roll forward or back to another digest—not into a unique snowflake.
The replace-don’t-patch loop
Build a golden artifact
AMI, machine image, or container digest from a pipeline, not from a logged-in host.
Scan and sign that digest
CVE, secret, and policy checks apply to the bits you will actually boot.
Roll out new instances
ASG refresh, blue/green, or Kubernetes rolling update places new copies beside or instead of old ones.
Drain and destroy the old
The previous generation is terminated so SSH souvenirs cannot linger.
Observe and roll back by version
Health checks fail? Deploy the previous known digest. Do not hotfix the broken generation in place.
Mutable habits that break the model
SSH as a release tool
Config files edited on the box diverge from git within a day.
In-place package upgrades
unattended-upgrades on long-lived VMs create unique patch levels per node.
kubectl exec as a package manager
Installing tools in a running container makes the next replica different.
Console security-group tweaks
Live firewall edits that never return to IaC are mutable network infrastructure.
What should be immutable versus what must change
| Layer | Immutable practice | Still changes |
|---|---|---|
| Compute (VMs, nodes) | Replace the instance from a new image | Instance identity documents and attached roles |
| Application processes | New container digest, rolling update | In-memory state, caches (keep them disposable) |
| Configuration | Baked or injected from versioned config, not edited on disk | Feature flags via an API designed for it |
| Data | Engine/version replaced via new instances when possible | The dataset itself—backed up and migrated |
| Secrets | Images never contain live secrets | Rotated values from a secrets manager at runtime |
Immutable infrastructure checklist
- Build node and app images in CI; forbid “golden” images that were customized over SSH.
- Pin Kubernetes Deployments to image digests and use rolling or blue/green replacement.
- Disable or tightly break-glass SSH; record sessions and rebuild after any live change.
- Treat kubectl exec, docker exec, and package installs in running containers as incidents.
- Patch by baking: new AMI/image with the CVE fix, then rotate the fleet.
- Keep root filesystems read-only where the app allows; put scratch on emptyDir.
- Reconcile cloud resources to IaC so console edits cannot persist.
- Test rollback by redeploying the previous digest—not by reversing shell history.
The practical takeaway
Immutable infrastructure means production instances are disposable copies of a versioned image. You patch by replacing, you roll back by version, and you do not accumulate unique hosts.
IaC declares the cattle; immutability is the rule that nobody rides them as pets. If a change cannot be expressed as a new artifact, it will become drift—and drift is where both outages and attackers hide.
Related security terms
Infrastructure as Code (IaC)
The usual way to declare the replacement infrastructure that immutability depends on.
Container Image
The immutable unit Kubernetes already deploys if you pin digests and avoid in-place exec.
Reproducible Build
Proves the replacement image matches the intended source and toolchain.
Cloud Misconfiguration
Console hotfixes are the opposite of immutability and a common source of drift.
Patch Management
Still required—but applied by baking a new image, not by SSH on Friday night.
Frequently asked questions
What is immutable infrastructure in simple terms?
You do not log into a production server to “just change a file.” You build a new image or pod spec, roll it out, and throw the old instance away.
Is this the same as Infrastructure as Code?
IaC declares desired state. Immutability is an operational rule about instances: they are cattle, not pets. You can have IaC and still SSH-patch nodes; that is mutable infrastructure with extra YAML.
Do containers make infrastructure automatically immutable?
Only if you deploy new digests and forbid kubectl exec mutations, privileged debug, and writable root filesystems used as a package manager. A long-lived pod that apt-get upgrades itself is a pet.
How do you patch then?
Patch the pipeline: rebuild the AMI or image with the new packages, roll nodes or Deployments, drain, and terminate. Emergency live patches should be rare and followed by a rebuild that encodes the same change.
What about databases and disks?
Data volumes are mutable by nature. Immutability applies to compute and config. Back up data, version schema, and still replace the database *engine* via new instances when you can.
Does blue/green or rolling update equal immutability?
Those are rollout patterns. They support immutability when the new fleet is a new image, not the old VMs with a config tweak.
Is SSH always forbidden?
Break-glass SSH can exist with MFA, recording, and expiry. If SSH is how you ship, the fleet is not immutable.
References
Explore authoritative guidance and frameworks related to immutable infrastructure.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.