Immutable Workloads

This video is all about mutable workloads, the evolution to immutable workloads, some additional details on them. We'll examine a mutable workload pipeline. To really understand what an immutable workload is, let's take a look at the history of server management. In the traditional world, we took care of our servers, we gave them names, you treated them as pets. But in the immutable world, the perspective on servers changes. You look at them more like cattle. They have no names, no individualized treatment, just a herd of resources intended for a specific purpose. The traditional model states back to physical server management and virtual machine management. It's probably how you managed servers on-prem today and likely you do this to manage Cloud-based servers. This is where human admin is logging into the machine.

‍

They're deploying applications on top of a base operating system. Patching is taking place. With this human intervention, you can create configuration drift. Basically, you have a server that is a snowflake, very unique, something that you don't know how exactly it gotten to the state it got and you may not be able to reproduce it if you needed to. In this traditional model, there's also a high uptime expectation on servers because they're constantly running and just like your pets, you want them to stay around and be available. Progressing to automated management. This is where we still have some logins by humans, but much less. Item potent automation such as Ansible, chef, salt or puppet, is used to deploy applications and patch the operating systems. This also reduces the amount of configuration drift and it's easier to recreate the servers since the technologies like Ansible, chef, and salt are basically a collection of scripts that are used to install the applications and set up the virtual machine, and this allows you to recreate the virtual machine or a very comparable virtual machine at a future point in time. Finally, we get to the immutable. This is where you have a base image and you also have all the OS and all the applications deployed. In this paradigm, remote login is usually disabled.

‍

There's no patching our deployments to the running instances. This ensures no configuration drift, but it also increases the frequency that you're going to rotate the actual images and servers themselves. You may see this concept described as ephemeral, which is another way of saying lasting for a very short time. Just like the cow is to the herd, has a very limited lifetime in a very specific use, the same mindset is applied when you're dealing with immutable servers. Talking a little bit more about immutable workloads. There are some real security benefits. You don't patch the actual running systems. We've talked about that you'll actually recreate the image with the patches themselves already applied and then you will redeploy that server. You prevent changes without consistency. It simplifies the update roll-out with a replaced the server type mindset, and this includes when you have problematic instances that aren't behaving well, you just replace it. The immutable also provides a great opportunity to ensure your images are hardened.

‍

You can get to the level where you whitelist certain OS processes that are allowed to run, establish read only file systems, and setup file integrity alerts in case any of the local files do get modified on these machines because you're not expecting that to happen. All of this is really integrating security into the design testing and image creation process. It's an opportunity to shift left security and have these considerations accounted for closer to the actual development time instead of having security as an afterthought. There are also some implications when using immutable workloads. Consistent image creation process. You need to get this and we're going to talk about this in a second. You want to integrate security testing with that image creation. You'll disable and restrict logins before deploying to production because again, we don't want someone going onto this machine and manipulating our change in configuration, it's really intended to be used as is. Local logs should be offloaded are fully externalized. We talked about ephemeral, being short-lived.

‍

These servers may not be around. If you expect to have the logs sit in the read writable sections and want to come back and check them on a weekly, monthly, yearly basis, that machine may be gone and so will those local logs. Finally, you want to manage a service catalog of the different images. This allows you to keep track of which images should be used for deploying which applications. It also allows you to take advantage of deep dive hardening efforts on certain images and create standards against which other individuals and teams can build off of. This workflow demonstrates an immutable workload pipeline. The process of creating these immutable servers. Starting on the far left, you have the server configuration, an image or container configuration, and source code. I'm using technologies like Packer and other Cloud providers specific solutions.

‍

These artifacts can be managed in version controlled directly for the CCSk exam, it's important to know that the security testing is integrated into the workload building pipeline. You have a continuous integration server and you have an automated process to ensure and perform checks and balances to make sure that the produced image will be compliant with the various policies that you have. The more automated you can do this, the less demand is going to place on your security team to be involved in the day-to-day development activities of different teams as they are revising and amending their server images.

‍

When the security tests have been complete, you end up producing a master image file. This image file is then undergoes manual or automated acceptance testing and it gets deployed to the "Cloud" hopefully using an automated procedure. In this video, we went over the evolution of immutable workloads. We talked more about immutable workloads, the security benefits and the implications, and then we examined immutable workload Python, how security is integrated into the process of creating these immutable workloads.