Container Security: Why Bother?

Are containers secure?

Probably not. But knowing each approach’s strengths and risks—and available options—could help ease adoption.

Such a decision requires two primary considerations:

  • Containers do not provide the same level of isolation between apps running on the same host as virtual machines (VMs) provide.
  • Containers don’t provide the same level of isolation on the host, especially where running with root privileges.

Running Containers in Virtual Machines

VMware is a great supporter of the concept of running each containerized application in a single virtual machine, which increases security. Placing a container in its own dedicated virtual machine provides better isolation from the host machine and, naturally, from other VMs and containers running on those VMs.

But running containers in a virtual machine seems to negate many of the container benefits, such as faster start/stop, consolidation, packaging and performance comparable to running on bare metal,  to name just a few.

As container adoption accelerates, container security is among other unresolved mysteries that need to be carefully examined and appropriately addressed, such as how to containerize stateful apps. Typical security related areas for look for are:

  • User access – Assuring each user has access only to their application components and containers.
  • Securing and certifying container images and patches.
  • Securing (encrypting) data in flight.
  • Securing (encrypting) data at rest.

Container Security Issues

Failing to address part or all of the above could lead to significant problems:

  • Kernel exploits > host shut-down: Unlike in a VM, with containers the kernel is shared among all containers and the host. If a container causes a kernel panic, it will take down the entire host.
  • Denial-of-service attacks: By design all containers share the same kernel resources, so if one container “takes over” key resources it essentially degrades the performance of other containers on the same host, causing a denial of service (DoS). As a result, legitimate users are unable to access part or all of the system.
  • Container breakouts: By default, users are not namespaced, so any process that breaks out of the container will have the same privileges on the host as it did in the container. If you were root in the container, you will be root on the host. Given that container technology is still nascent, we simply assume that container breakouts are not as common, but possible.

Docker and LXC

Docker containers are very similar to LXC containers, and they have similar security features (built/designed atop the cgroups and kernel namespaces architecture), especially if you take care of running your processes inside the containers as non-privileged users (i.e. non-root).

When you start a Docker container, Docker creates a set of namespaces and control groups for the container.

Namespaces will cover the first and most straightforward isolation. Processes running within a container cannot see processes running in another container or in the host system. Each container also gets its own network stack, so a container doesn’t get privileged access to the sockets or interfaces of another container.

Control Groups (a component of Linux kernel) implement resource accounting, limiting, prioritization and control. These help assure that each container gets the required memory and CPU (not disk I/O control).

You can add an extra layer of safety by enabling AppArmor, SELinux, GRSEC or other preferred hardening options.

LXC is a “userspace” interface to Linux kernel containment features and uses the following to contain/isolate processes:

  • Kernel namespaces (ipc, uts, mount, pid, network and user)
  • Apparmor and SELinux profiles
  • Seccomp policies
  • Chroots (using pivot_root)
  • Kernel capabilities
  • CGroups (control groups)

Application containers, whether implemented using Docker or LXC, clearly are gaining momentum. As container technology and usage expand and mature, it is necessary to address security considerations. The Docker blog, “Security should be part of the platform,” provides a helpful reference.

Equally important is the ability to react effectively and efficiently to live threats by clearly defining application borders, privileges and resource pools, as well as user roles/groups (RBAC). Always keep in mind that addressing the security gaps requires a holistic end-to-end approach—solving point problems might seem an acceptable short-term fix, but potentially will impose even greater risks in the long term.

Specialist Container Security Software

The initial approach to security typically pursued is to apply the same measures of security to containers as were applied to physical machines. Recently, we have seen new software designed specifically to meet the security requirements of containers.

Review your application security exposure and prepare accordingly. Avoid reinventing the wheel—use tested and certified services.

Smarter platforms are built using microservices and expose a set of REST APIs enabling control of all aspects of infrastructure, including security.

These providers offer a wealth of complementary and beneficial information:

Twistlock: https://www.twistlock.com
Aquasec: https://www.aquasec.com
Blackduck: https://www.blackducksoftware.com

About the Author / Razi Sharir

RaziSharirRazi Sharir is vice president of Products at Robin Systems.