Immutable Infrastructures come with Improved Security as a side-effect
The major takeaway with immutable infrastructures is that you should never change/mutate any parts of your system once deployed. If you need to make changes, deploy a new server defined by your configuration files instead. With a good implementation, immutable infrastructures makes continuous deployment less complex and more certain.
A rootkit is a set of programs that enables someone obtain root/admin level access to a system.
This feature of immutable deployments can come in handy when tackling security intrusions in your system. A great example to think of is a rootkit. A rootkit is a set of programs that enables someone obtain root/admin level access to a system. Hackers often use it to create a backdoor to your system. They are usually hard to detect especially when you don’t know what you’re looking for. Rootkits help hackers find their way back in whenever you identify and neutralize other exploits they’ve deployed. It becomes easy for them to redeploy hacks. Ever wondered how you keep getting hit by the same intrusions over and over again? Even after patching up vulnerabilities in your system. It might be a rootkit that’s doing you over.
If your system change is as a result of an immutable deployment workflow, any changes that aren’t on your configuration file won’t be applied on the new server. And now, the rootkits done! To complement this, ensure you carry out system audits on the current server configuration against your original configuration files used during deployment. They should be the same. If something’s changed, it might be the key to identifying and fixing a vulnerability in your config files before your next deployment.
A server infrastructure architecture where platform changes in any layer of your stack are achieved by building new servers and destroying old ones instead of upgrading them in-place.
If you are interested in learning more about immutable infrastructures, keep these two things in mind:
- What is it: A server infrastructure architecture where platform changes in any layer of your stack are achieved by building new servers and destroying old ones instead of upgrading them in-place.
- Why do we use it: To reduce complexity and increase certainty in configuration management when it comes to a server’s state. As much as system upgrades and rollbacks are manageable at an incremental scale, it’s hard to be 100% certain that changes you make are executed as expected.
Posts you may also find interesting
Originally published at https://www.linkedin.com on August 24, 2016.
