Dave Pinkawa: Hello, and welcome to this video on
hardening your Docker hosts. The first and most
important thing you can do to maintain the
security of your Docker hosts is to keep them
updated. At the Docker COI, you could use the
Docker dash dash version to get the version
number, and then check the Docker engine release
notes page at the Docker website. As you can see,
some of the older versions of Docker do have some
common vulnerabilities and exposures CVE ease that
afflict them, it is a good idea to get ahead of
your patching and keep your hosts updated so that
you are not exposed to any of those particular
vulnerabilities. In the case of most operating
systems, you will have installed Docker through
your package management solution. So you should
install each of those components make sure that
they are updated as well on a regular basis. This
can be part of a larger patching strategy that you
might have at your organization. But if it is a
single host, you can go ahead and install those
updates for each of those individual components at
the same time. As you can see here, we use the
Ubuntu apt package manager to install an update
any available updates for the three main packages
that Docker CE relies on. With our update
successfully installed we can once again run the
Docker version command and just confirm that our
version is up to date. The next security conscious
choice for hardening our hosts is choosing to run
only those secure images that we trust. It is
common on Docker hub to have verified publishers
and official images from community package
maintainers or those organizations that have a
commercial backing. By using only those verified
publisher based images, you are ensured that
you're not running any sort of malicious code
underneath. So the next time you're going to
deploy a solution via Docker Hub, just make sure
that you trust the publisher. In the same vein of
trusting the publisher on Docker Hub, you can run
a Docker registry local to your own environment.
This can be on your workstation, this could be
inside of your own data center. But there is a
container image that will provide and do this for
you. In our Docker file, we are just pulling the
latest version of the Docker registry container
image, we're exposing Port 5000 as well. And then
we're going to bring this up with our compose file
just so that we could set the parameter of restart
always so that even if our host goes down, this
container will always attempt to come back up
online. Here we're going to bring up our registry
container using the Docker compose up command,
we're going to use dash D to make sure that this
comes up as a daemon in the background. Here, we
can confirm that our registry container has come
online successfully. And now let's put our local
registry to the test, we're going to pull the
Ubuntu image directly from Docker hub to our
workstation. And then we're going to initiate a
push to our local registry using just a couple of
different tags to specify a new location. So we're
tagging that image that we just pulled off of
Docker Hub, we're specifying the new location and
the name that we want to put push it to. And then
we're actually going to use the Docker push
command and specify which location we are pushing
this image to. Here we see it is successfully
getting pushed to our local registry that is
awesome. This is a registry that we can then trust
to be separate and not exposed to any public users
or other modifications that we don't make to it.
And then just to give it one final test, we're
going to pull that image from our local registry
and OVC it is pulled it is successful. The image
that we are using on this Docker host is the one
that comes from a registry that we own. Our third
tactic and hardening our Docker hosts is to
actually change which user account is being used
within the container itself to run your app. By
default within a container, it will always run the
app as the root user. So to change this default
behavior, we need to do a few things. The first is
going to be running several commands one of them
to create a group inside of our container. We're
going to create then a new user named after user
and we're going to add it to that app group. And
then we're going to assign the ownership of our
app folder within the container to the group in
user that we just created.
Finally, we're going to use the user command and
we're going to specify which user we want our
container to run as. So in this instance, we're
going to be running the container and the contents
within our container as the app underscore user
user account. So by using this user instruction
set inside of our Docker file, we're specifying
for the container which user we want to execute
all of the run commands as well as the container
itself, by running as the non root user in the
event that there is a success curity breach to
this container. He writes of that breach will not
be of the root user instead, but will be of just
some lesser standard user that can only execute
this one application. The next security measure
that we're going to take for our Docker host is a
much more involved process. It's actually going to
be revolved around namespace isolation on our
host. To implement this type of remapping feature,
Docker does provide two utilities that we're going
to enable and leverage, one of them being the dock
remap utility, and then the other is user ns
remap. The first step in this process is going to
our Etsy default Docker configuration file. And
we're going to add a Docker option to include
another configuration file for when it's being run
as a service. We're going to tell Docker, that
when it's run as a service to also look at this
demon dot JSON configuration file for some
additional JSON based options to be enabled. Now,
we're going to both create and edit that demon
JSON file. And we're going to specify the user and
s remap functionality to be enabled. With our user
namespace remapping feature enabled on Docker, our
next step is to actually assign the subordinate
user and group identification for the doc remap
user that the Docker service is going to run us.
Without these impersonations Dockers not going to
know which user it is allowed to run as, as a
service. To ensure our change takes effect, we're
just going to restart the service real quick. And
then we can also confirm that our subordinate user
and group identification files have the doc remap
user as we created above. Docker will now
successfully run as these non root users when
executing any of your containers. And our last
security measure for our Docker host is actually
something to implement at runtime of your
containers. And this is implementing resource
limits so that your containers don't accidentally
consume more than they should. You can see these
limits in effect in our Docker compose above,
underneath the deploy heading in our Docker
compose file. And then also under Resources, we
have those limits set the CPU being half of one
CPU and then the memory being a maximum of 512
megabytes. And a quick fun way to confirm that
these limits are in fact in place is by using the
Docker stats command and we can see underneath the
memory usage heading, that there is a limit
imposed on our memory consumption for this
particular container. I hope that this video has
been informative on how you can harden your Docker
container host. Thank you