Security through Immutable Infrastructure

Rather than the traditional approach of upgrading code on existing systems, with immutable infrastructure new code is deployed to a new set of servers. As teams adopt this approach, automation will improve, code coverage will increase, and your plan for business continuity will receive an uplift.

It's worth taking every precaution when it comes to IT security. Embracing an immutable infrastructure, an approach where after initial code deployment changes are prohibited on the running system, can improve your overall security posture. Rather than the traditional approach of upgrading or releasing new code onto and existing system, with the immutable infrastructure approach revised code and configuration are deployed to a new set of infrastructure, physically and/or logically separated. Once the updated deployment has been validated and tested, production traffic is directed to the new infrastructure and the previous version is torn down.

An image of a bird rendered in flames
"Phoenix", Photo by Marek Piwnicki on Unsplash

It's the act of tearing down that has significant security implications. Kornelis Sietsma coined the phrase Phoenix Servers in support of immutability to describe the process of new infrastructure rising from the ashes of the previous iteration.

We hear about it all the time, aging systems (technical debt) are left to oxidize, leaving open security vulnerabilities. Often times hackers are in these systems for lengthy periods, only realized in a post event forensic investigation. If we set a Time To Live (TTL) on our host environments, forcing us to replace them with each new deploy, the set of vulnerable systems would greatly shrink. Want to put this to the test? Produce a histogram of the uptime of your servers right now, I bet that's an eyebrow raising chart.

As teams come to grips with this approach to systems operations, automation will improve, code coverage will increase, and your plan for business continuity will receive an uplift. No one will be excited to build by hand if each sprint requires new hardware, this approach will force a maturity for code deployment.

The economics support this too, as companies shift more workload to the public cloud. You are no longer financially incented to run on the hardware you've purchased and depreciating for the next four years. The pay-as-you-go model of the cloud, combined with elasticity and server-less architecture (i.e. AWS Lambda or Azure Functions), are perfectly aligned for immutability.

There is a cultural impact, yet the world is changing, and the blurring of the lines between development and operations engineering is real. Embracing immutability has plenty of benefits, and top of the list ought to be the improvement to security that burning down your server farm will provide.