Practical Container Security by Mrunal Patel and Thomas Cameron, Red Hat

Practical Container Security
Mrunal Patel
Principal Software Engineer
Thomas Cameron
Cloud Strategy Evangelist

3
AGENDA
Containers and Security
INTRODUCTION
Who are we, and why should you care? What makes up container security?
RED HAT AND CONTAINERS
A brief history
KERNEL NAMESPACES
What are they?
WHAT ARE CONTAINERS?
How do they work?
WHAT ARE CONTAINERS NOT?
Mythbusting
CONTAINER SECURITY

4
AGENDA
Containers and Security
CONTROL GROUPS
What are they?
THE DOCKER DAEMON
How it works and the security it provides
LINUX KERNEL CAPABILITIES
libcap and how Docker deals with it
SELINUX
What it is, what it does, and why it matters
TIPS AND TRICKS
What do do, and what not to do.
THE DOCKER DAEMON CONCLUSIONS
Go forth and contain!

6
INTRODUCTION
Who am I, and why should you care?
My name is Thomas Cameron, and I'm the global solutions architect leader at Red
Hat.
●
In IT since 1993
●
I was a police officer before that, educational background is in law enforcement &
security
●
At Red Hat since 2005
●
Red Hat Certified Architect, Red Hat Certified Security Specialist, and other certs
●
In the past, I was an MCSE, a MCT, and a CNE
●
Spent a lot of time focusing on security in organizations like banks, manufacturing
companies, e-commerce, etc.
●
I do NOT know everything. But I have some pretty impressive scars.

8
A brief history
Red Hat has been working on container technologies since before 2010
●
Makara acquisition 2010 – PaaS
●
Rebranded as OpenShift
●
“Cartridges” using SELinux, cgroups, kernel namespaces
●
Docker came to prominence in 2013(-ish)
●
Docker gained community adoption and we started participating in 2013.
Meritocracy rules!
●
Red Hat is a top contributor to Docker (#2 behind Docker at last check)

9
A brief history
Industry adoption of Docker is incredible
●
Docker has been through multiple successful venture capital rounds
●
Apcera, Cisco, EMC, Fujitsu Limited, Goldman Sachs, HP, Huawei, IBM, Intel,
Joyent, Mesosphere, Pivotal, Rancher Labs, Red Hat and VMware are all on board
with container standardization with Docker.

10
A brief history
Industry adoption of Docker is incredible
●
Even Microsoft announced that they will support Docker containers!

13
How do they work?
Containerization, specifically Docker, is a technology which allows applications (web,
database, app server, etc.) to be run abstracted from, and in some isolation from, the
underlying operating system. The docker service can launch containers regardless of
the underlying Linux distro.
Containers can enable incredible application density, since you don't have the
overhead of a full OS image for each app. Linux control groups also enable maximum
utilization of the system.
The same container can run on different versions of Linux
●
Ubuntu containers on Fedora
●
CentOS containers on RHEL

14
How do they work?
OK, maybe not...
Containers make it really easy for application developers to build and deploy apps.

16
Mythbusting
Containers are not a panacea. They are not “the cure to all that ails you!”

17
Mythbusting
Containers are not a fit for every application.

18
Mythbusting
They are not virtualization. You can run containers on an OS on bare metal.

20
CONTAINER SECURITY
What makes up container security?
Containers use several mechanisms for security:
●
Linux kernel namespaces
●
Linux Control Groups (cgroups)
●
The Docker daemon
●
Linux capabilities (libcap)
●
Linux security mechanisms like AppArmor or SELinux

22
LINUX KERNEL NAMESPACES
What are they?
Namespaces are just a way to make a global resource appear to be unique and
isolated. The namespaces that the Linux kernel can manage are:
●
Mount namespaces
●
PID namespaces
●
UTS namespaces
●
IPC namespaces
●
Network namespaces
●
User namespaces

24
What are they?
Mount namespaces allow a container to “think” that a directory which is actually
mounted from the host OS is exclusively the container's.
When you start a container with the -v [host-path]:[container-path]:[rw|ro] argument,
you can mount a directory from the host in the container. The container “sees” the
directory in its own mount namespace, not knowing that it is actually on the host. So
multiple containers could, for instance use the host's /var/www/html directory without
having to copy content to all the containers.

27
What are they?
PID namespaces let the container think it's a new instance of the OS. When you start
a container on a host, it will get a new process ID. PID namespaces enable the
container to “see” the PIDs inside the container as unique, as if the container were its
own instance of an OS.
In the following example, I launch a Fedora container running bash, and run “ps ax”
The container only “sees” its own PID namespace, so the bash process exists within
the container as PID 1. On the host, however, the docker process is PID 18557:

31
What are they?
When you start a container, assuming you've added your user to the docker group,
you start it as your user account. In the following example, I start the container as
tcameron. Once the container is started, my user inside the container is root. This is
an example of user namespaces.

34
What are they?
Network namespaces allow a container to have its own IP address, independent of
that of the host. These addresses are not available from outside of the host, this is
private networking similar to that of virtualization. The Docker service sets up an
iptables masquerading rule so that the container can get to the rest of the Internet.
In the following query, I find that my Fedora instance has the address 172.17.0.7,
even though the host doesn't have an address associated with the ethernet interface:

37
What are they?
IPC namespaces do the same thing with interprocess communications. My container
has no IPCs mapped, but my host has many:

41
What are they?
UTS (UNIX Timesharing System) namespaces let the container “think” it's a separate
OS, with its own hostname and domain name:

45
CONTROL GROUPS
What are they?
From the documentation at
https://www.kernel.org/doc/Documentation/cgroups/cgroups.txt:
“Control Groups provide a mechanism for aggregating/partitioning sets of tasks, and
all their future children, into hierarchical groups with specialized behavior.”
This allows us to put various system resources into a group, and apply limits to it, like
how much disk IO, CPU use, memory use, network use, namespaces, and so on. In
the case of containers, the resources are those assigned to that container.

46
CONTROL GROUPS
What are they?
This ensures that, even if a container is compromised (or just spins out of control),
there are limits in place which minimizes the risk of that misbehaved container
impacting the host or other containers.

47
CONTROL GROUPS
What are they?
Note that when I run the command systemctl status docker.service, I get the control
group and slice information:

49
CONTROL GROUPS
What are they?
You can navigate the /sys/fs/cgroup/ pseudo-directory to see what resources are
allocated to your containers.
There are over 8500 entries in this directory on my system, so it is not practical to talk
about the details of individual cgroups, but you can get information about memory,
cpu, block I/O, network I/O, and so on here.

52
THE DOCKER DAEMON
The docker daemon (/usr/bin/docker) is responsible for managing the control groups,
orchestrating the namespaces, and so on so that docker images can be run and
secured.
Because of the need to manage kernel functions, Docker runs with root privileges. Be
aware of this!

53
THE DOCKER DAEMON
There are some considerations for running Docker:
●
Only allow trusted users to run docker. The Docker documentation recommends
that you add users to the docker group so they can run docker commands. With
this flexibility comes risk. Make sure you only delegate this ability to trusted users.
Remember that they can mount the host filesystem in their container with root
privileges!
●
If you are using the REST API to manage your host(s), make sure you do not have
vulnerabilities exposed. Ensure you have strong authentication.
●
Use SSL if you are going to expose the REST API over http. Don't expose it except
to secured networks or VPN.

(libcap)

55
The root user historically had the ability to do anything, once authenticated. Linux
capabilities is a set of fine grained controls which allow services or even users with
root equivalence to be limited in their scope.
It also allows non-root users to be granted extra privileges. A regular user, for
instance, could be granted the net_bind_service capability and they could bind a
service to a privileged port (below 1024).

56
In containers, many of the capabilities to manage network and other services are not
actually needed. SSH services, cron, services, filesystem mounts and unmounts are
not needed, network management is not needed, etc.
By default, Docker disallows many root capabilities, including the ability to modify
logs, change networking, modify kernel memory, and the catch-all CAP_SYS_ADMIN.

59
SELINUX
Security Enhanced Linux (SELinux) is a mandatory access control system.
Processes, files, memory, network interfaces, and so on are labeled, and there is a
policy which is administratively set and fixed.
That policy will determine how processes can interact with files, each other, network
ports, and the like.

60
SELINUX
SELinux is primarily concerned with labeling and type enforcement. For a mythical
service “foo,” the executable file on disk might have the label foo_exec_t. The startup
scripts for foo might have the label foo_config_t. The log files for foo might have the
label foo_log_t. The data for foo might have the label foo_data_t. When foo is running,
the process in memory might have the label foo_t.
Type enforcement is the rule set that says that when a process running in the foo_t
context tries to access a file on the filesystem with the label foo_config_t or
foo_data_t, that access is allowed. When the process with the label foo_t tries to write
to a log file with the foo_log_t, that would be allowed, as well. Any other access,
unless explicitly allowed by policy, is denied.

61
SELINUX
If the foo process, running in the foo_t context tries to access, for instance, the
directory /home/tcameron, with the label user_home_dir_t, even if the permissions are
wide open, the policy will stop that access.
SELinux labels are stored as extended attributes on the filesystem, or in memory.

62
SELINUX
SELinux labels are stored in the format:
●
selinux_user:selinux_role:selinux_type:mls:mcs
So for the mythical “foo” service, the full syntax for the label of the running process
might be:
●
user_u:object_r:foo_t:s0:c0

63
SELINUX
The default policy for SELinux is “targeted.” In the targeted policy, we don't use the
SELinux user or role, so we'll ignore them for today. We will also ignore the MLS
(multilevel security) label, since that is only used in the MLS policy (think top secret
vs. secret in the military).
We really only care about the type (remember, type enforcement) and the MCS label.
Think of MCS labels as extra identifiers. In SELinux for containers, we can be very
granular about which processes can access which other processes.
These are different labels:
●
●

64
SELINUX
Type enforcement says that a process with the first label is different from the process
with the second. So policy would prevent them from interacting. Also, there is no
policy allowing a process running with those labels to access the filesystem unless it
is labeled with foo_config_t or foo_content_t or another defined label.
Neither of those processes would be able to access /etc/shadow, which has the label
shadow_t.

65
SELINUX
On a standalone system running Docker, all of the containers run in the same context
by default. In Red Hat's PaaS offering, OpenShift, this is not the case. Each Openshift
container runs in its own context, with labels like:
●
staff_u:system_r:openshift_t:s0:c0,c1
●
●
So, even if someone were to gain access to the docker container process on the host,
SELinux would prevent them from being able to access other containers, or the host.

66
SELINUX
In the following example, I emulate an exploit where someone takes over a container.
I use runcon (run in the context) to set my context to that of an Openshift container.
I attempt to access /etc/shadow (shadow_t label). I try to write to the filesystem. I try
to read the contents of a user's home directory.

69
TIPS AND TRICKS
What to do, and what not to do
Containers are, at the end of the day, just processes running on the host. Use
common sense.

70
TIPS AND TRICKS
Do:
●
Have a process in place to update your containers. Follow it.
●
Run services in the containers with the lowest privilege possible. Drop root
privileges as soon as you can.
●
Mount filesystems from the host read-only wherever possible.
●
Treat root inside the container just like you would on the host.
●
Watch your logs.

71
TIPS AND TRICKS
Don't:
●
Download any old container you find on the 'net.
●
Run SSH inside the container.
●
Run with root privileges.
●
Disable SELinux.
●
Roll your own containers once, and never maintain them.
●
Run production containers on unsupported platforms.

73
CONCLUSION
Go forth and contain!
Containers are incredibly cool. They make application deployment really, really easy.
They leverage some incredible capabilities within the Linux kernel. By design, they
are relatively secure, but there are some gotchas.
As with every other piece of software out there, docker tech requires some feeding
and maintenance. Well maintained, containers can make your business more agile,
less complex, and safe.

Practical Container Security by Mrunal Patel and Thomas Cameron, Red Hat

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Practical Container Security by Mrunal Patel and Thomas Cameron, Red Hat (20)

More from Docker, Inc. (20)

Recently uploaded (20)

Practical Container Security by Mrunal Patel and Thomas Cameron, Red Hat