Containers & Security
2 likes508 views
Containers provide security through mechanisms like kernel namespaces, control groups (cgroups), and SELinux labels. The Docker daemon manages these mechanisms to isolate containers and apply resource limits. While containers enable application density and portability, administrators must still practice secure configuration by limiting container privileges, updating containers regularly, and monitoring logs. When used properly, containers can improve security by isolating applications and minimizing the risk of compromise.
![26
LINUX KERNEL NAMESPACES
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.](https://image.slidesharecdn.com/cameroncontainersandsecurity-151120140316-lva1-app6892/85/Containers-Security-26-320.jpg)
Containers & Security
- 1. CONTAINERS AND SECURITY Tips, Tricks, and Mythbusting Thomas Cameron, RHCA, RHCDS, RHCSS, RHCVA, RHCX Global Solutions Architect Leader October 19th , 2015
- 2. AGENDA
- 3. 3 AGENDA Containers and Security - All Things Open, October 19th , 2015 INTRODUCTION Who am I 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. 4 AGENDA Containers and Security - All Things Open, October 19th , 2015 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!
- 5. INTRODUCTION
- 6. 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.
- 7. 7
- 8. RED HAT AND CONTAINERS
- 9. 9 RED HAT AND CONTAINERS 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)
- 10. 10 RED HAT AND CONTAINERS 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.
- 11. 11 RED HAT AND CONTAINERS A brief history Industry adoption of Docker is incredible ● Even Microsoft announced that they will support Docker containers!
- 12. 12
- 14. 14 WHAT ARE CONTAINERS? 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
- 15. 15 HUMAN SACRIFICE! DOGS AND CATS, LIVING TOGETHER! MASS HYSTERIA!
- 16. 16 HUMAN SACRIFICE! DOGS AND CATS, LIVING TOGETHER! MASS HYSTERIA!
- 17. 17 WHAT ARE CONTAINERS? How do they work? OK, maybe not... Containers make it really easy for application developers to build and deploy apps.
- 18. WHAT ARE CONTAINERS NOT?
- 19. 19 WHAT ARE CONTAINERS NOT? Mythbusting Containers are not a panacea. They are not “the cure to all that ails you!”
- 20. 20 WHAT ARE CONTAINERS NOT? Mythbusting Containers are not a fit for every application.
- 21. 21 WHAT ARE CONTAINERS NOT? Mythbusting They are not virtualization. You can run containers on an OS on bare metal.
- 23. 23 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
- 25. 25 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
- 26. 26 LINUX KERNEL NAMESPACES 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. 27
- 28. 28 LINUX KERNEL NAMESPACES 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:
- 29. 29
- 30. 30
- 31. 31 LINUX KERNEL NAMESPACES 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.
- 32. 32
- 33. 33 LINUX KERNEL NAMESPACES 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:
- 34. 34
- 35. 35 LINUX KERNEL NAMESPACES What are they? IPC namespaces do the same thing with interprocess communications. My container has no IPCs mapped, but my host has many:
- 36. 36
- 37. 37
- 38. 38 LINUX KERNEL NAMESPACES What are they? UTS namespaces let the container “think” it's a separate OS, with its own hostname and domain name:
- 39. 39
- 40. 40
- 41. CONTROL GROUPS
- 42. 42 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.
- 43. 43 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.
- 44. 44 CONTROL GROUPS What are they? Note that when I run the command systemctl status docker.service, I get the control group and slice information:
- 45. 45
- 46. 46 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.
- 47. 47
- 49. 49 THE DOCKER DAEMON How it works and the security it provides 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!
- 50. 50 THE DOCKER DAEMON How it works and the security it provides 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.
- 52. 52 LINUX KERNEL CAPABILITIES libcap and how Docker deals with it 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).
- 53. 53 LINUX KERNEL CAPABILITIES libcap and how Docker deals with it 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.
- 54. 54
- 55. SELINUX
- 56. 56 SELINUX What it is, what it does, and why it matters 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.
- 57. 57 SELINUX What it is, what it does, and why it matters 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.
- 58. 58 SELINUX What it is, what it does, and why it matters 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.
- 59. 59 SELINUX What it is, what it does, and why it matters 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
- 60. 60 SELINUX What it is, what it does, and why it matters 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: ● user_u:object_r:foo_t:s0:c0 ● user_u:object_r:foo_t:s0:c1
- 61. 61 SELINUX What it is, what it does, and why it matters 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.
- 62. 62 SELINUX What it is, what it does, and why it matters 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 ● staff_u:system_r:openshift_t:s0:c2,c3 ● staff_u:system_r:openshift_t:s0:c4,c5 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.
- 63. 63 SELINUX What it is, what it does, and why it matters 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.
- 64. 64
- 65. TIPS AND TRICKS
- 66. 66 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.
- 67. 67 TIPS AND TRICKS What to do, and what not to do 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.
- 68. 68 TIPS AND TRICKS What to do, and what not to do 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.
- 69. CONCLUSION
- 70. 70 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.