Immutable Workloads

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
or

Already have an account? Sign In »

Time
9 hours 59 minutes
Difficulty
Intermediate
CEU/CPE
10
Video Transcription
00:01
>> This video is all about mutable workloads,
00:01
the evolution to immutable workloads,
00:01
some additional details on them.
00:01
We'll examine a mutable workload pipeline.
00:01
To really understand what an immutable workload is,
00:01
let's take a look at the history of server management.
00:01
In the traditional world,
00:01
we took care of our servers,
00:01
we gave them names,
00:01
you treated them as pets.
00:01
But in the immutable world,
00:01
the perspective on servers changes.
00:01
You look at them more like cattle.
00:01
They have no names, no individualized treatment,
00:01
just a herd of resources intended for a specific purpose.
00:01
The traditional model states back to
00:01
physical server management
00:01
and virtual machine management.
00:01
It's probably how you managed servers on-prem today
00:01
and likely you do this to manage Cloud-based servers.
00:01
This is where human admin is logging into the machine.
00:01
They're deploying applications on
00:01
top of a base operating system.
00:01
Patching is taking place.
00:01
With this human intervention,
00:01
you can create configuration drift.
00:01
Basically, you have a server that is
00:01
a snowflake, very unique,
00:01
something that you don't know how
00:01
exactly it gotten to the state it
00:01
got and you may not be able to
00:01
reproduce it if you needed to.
00:01
In this traditional model,
00:01
there's also a high uptime expectation on
00:01
servers because they're constantly
00:01
running and just like your pets,
00:01
you want them to stay around and be available.
00:01
Progressing to automated management.
00:01
This is where we still have
00:01
some logins by humans, but much less.
00:01
Item potent automation such as Ansible, chef,
00:01
salt or puppet, is used to deploy
00:01
applications and patch the operating systems.
00:01
This also reduces the amount of
00:01
configuration drift and it's easier
00:01
to recreate the servers since
00:01
the technologies like Ansible, chef,
00:01
and salt are basically a collection of scripts that are
00:01
used to install the applications
00:01
and set up the virtual machine,
00:01
and this allows you to recreate the virtual machine or
00:01
a very comparable virtual machine
00:01
at a future point in time.
00:01
Finally, we get to the immutable.
00:01
This is where you have a base image and you also have
00:01
all the OS and all the applications deployed.
00:01
In this paradigm, remote login is usually disabled.
00:01
There's no patching our deployments
00:01
to the running instances.
00:01
This ensures no configuration drift,
00:01
but it also increases the frequency that you're going to
00:01
rotate the actual images and servers themselves.
00:01
You may see this concept described as ephemeral,
00:01
which is another way of saying
00:01
lasting for a very short time.
00:01
Just like the cow is to the herd,
00:01
has a very limited lifetime in a very specific use,
00:01
the same mindset is applied when you're
00:01
dealing with immutable servers.
00:01
Talking a little bit more about immutable workloads.
00:01
There are some real security benefits.
00:01
You don't patch the actual running systems.
00:01
We've talked about that you'll actually
00:01
recreate the image with
00:01
the patches themselves already
00:01
applied and then you will redeploy that server.
00:01
You prevent changes without consistency.
00:01
It simplifies the update roll-out
00:01
with a replaced the server type mindset,
00:01
and this includes when you have
00:01
problematic instances that aren't behaving well,
00:01
you just replace it.
00:01
The immutable also provides
00:01
a great opportunity to ensure your images are hardened.
00:01
You can get to the level where you whitelist
00:01
certain OS processes that are allowed to run,
00:01
establish read only file systems,
00:01
and setup file integrity alerts in case any of
00:01
the local files do get modified on
00:01
these machines because you're not
00:01
expecting that to happen.
00:01
All of this is really integrating security into
00:01
the design testing and image creation process.
00:01
It's an opportunity to
00:01
shift left security and have these considerations
00:01
accounted for closer to
00:01
the actual development time
00:01
instead of having security as an afterthought.
00:01
There are also some implications
00:01
when using immutable workloads.
00:01
Consistent image creation process.
00:01
You need to get this and we're going
00:01
to talk about this in a second.
00:01
You want to integrate security testing
00:01
with that image creation.
00:01
You'll disable and restrict logins
00:01
before deploying to production because again,
00:01
we don't want someone going onto this machine
00:01
and manipulating our change in configuration,
00:01
it's really intended to be used as is.
00:01
Local logs should be offloaded are fully externalized.
00:01
We talked about ephemeral, being short-lived.
00:01
These servers may not be around.
00:01
If you expect to have the logs sit in
00:01
the read writable sections and want to come
00:01
back and check them on a weekly,
00:01
monthly, yearly basis, that machine may
00:01
be gone and so will those local logs.
00:01
Finally, you want to manage a service
00:01
catalog of the different images.
00:01
This allows you to keep track of which images
00:01
should be used for deploying which applications.
00:01
It also allows you to take advantage
00:01
of deep dive hardening efforts on
00:01
certain images and create standards against
00:01
which other individuals and teams can build off of.
00:01
This workflow demonstrates
00:01
an immutable workload pipeline.
00:01
The process of creating these immutable servers.
00:01
Starting on the far left, you have
00:01
the server configuration,
00:01
an image or container configuration, and source code.
00:01
I'm using technologies like Packer and
00:01
other Cloud providers specific solutions.
00:01
These artifacts can be managed in version
00:01
controlled directly for the CCSk exam,
00:01
it's important to know that the security testing is
00:01
integrated into the workload building pipeline.
00:01
You have a continuous integration server and you have
00:01
an automated process to ensure and perform checks
00:01
and balances to make sure that the produced image
00:01
will be compliant with
00:01
the various policies that you have.
00:01
The more automated you can do this,
00:01
the less demand is going to place
00:01
on your security team to be involved in
00:01
the day-to-day development activities of
00:01
different teams as they are revising
00:01
and amending their server images.
00:01
When the security tests have been complete,
00:01
you end up producing a master image file.
00:01
This image file is then undergoes
00:01
manual or automated acceptance testing and it gets
00:01
deployed to the "Cloud"
00:01
hopefully using an automated procedure.
00:01
In this video, we went over
00:01
the evolution of immutable workloads.
00:01
We talked more about immutable workloads,
00:01
the security benefits and the implications,
00:01
and then we examined immutable workload Python,
00:01
how security is integrated into
00:01
the process of creating these immutable workloads.
Up Next