Immutable Workloads

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with

Already have an account? Sign In »

9 hours 59 minutes
Video Transcription
this video is all about mutable workloads, the evolution to immutable workloads, some additional details on them. And 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. It 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 resource is intended for a specific purpose.
The traditional model states back to physical server management and virtual machine management.
It's probably how you manage servers on Prem today, and likely you do this to manage cloud based servers. This is where Huberman Admin is logging into the machine. They're deploying applications on top of a base operating system. Patching is taking place, and 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 got into the state of got. And you may not be able to reproduce it if you needed to
in this traditional model. There's also high up time expectation on servers because they're constantly running and just like your pets, you want him to stay around and be available
and progressing. Toe Automated Management This is where we still have some Loggins by humans, but much less item. Potent automation such as answerable, 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 Answerable 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.
And finally, we get to the immutable. This is where you have a base image and you have to have all the OS and all the applications deployed. And this paradigm remote logging 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 gonna
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. So just like the cow is, 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 rollout with They 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 air hardened. You can go to the level where you white list certain OS processes that are allowed to run established, read only file systems and set up 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 an image creation process.
It's an opportunity to quote 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 gonna talk about this in a second.
You want to integrate security testing with that image creation. You'll disable and restrict Loggins before deploying to production, because again, we don't want someone going onto this machine and manipulating are changing the 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. Thes servers may not be around,
so if you expect to have the logs sit in the read rideable 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 the service catalog of the different images. This allows you to keep track of which images should be used for deploying which kind of applications. It also allows you to take advantage of
deep dive hardening efforts on certain images and create standards of against which
other individuals and teams can build off. This workflow demonstrates an immutable workload pipeline the process of creating these immutable servers. Starting on the far left, you have the server configuration and image or container configuration and source code using technologies like Packer and other cloud provider specific solutions.
These artifacts can be managed in version control directly
for the CCS. K examines 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 T
development activities of different teams as they're revising and amending their server images and when the security tests have been complete, event it producing a master image file. This image file is then undergoes manual or automated acceptance testing and gets deployed to the cloud, hopefully using an automated procedure.
In this video, we went over the evolution of the mutable workloads. We talked more about immutable workloads to security benefits and the implications. And then we examined immutable workload pipe and how security is integrated into the process of creating these immutable workloads.
Up Next
Certificate of Cloud Security Knowledge (CCSK)

This course prepares you to take the Certificate of Cloud Security Knowledge (CCSK) certification by covering material included in the exam. It explains how the exam can be taken and how CCSK certification process works.

Instructed By