Container Defense in Depth
The new age of image-based containers exploded onto the scene in early to mid-2013. Since the early days of the Docker container engine, we heard questions of whether they were secure enough. Our very own Dan Walsh was heard many times saying, “Docker containers don’t contain” — so the question is, can we safely use them? Especially in production?
Well, containers are really just fancy files and fancy processes which means that almost all of the current information assurance techniques we have are applicable to containers. In fact, many of the tools we have today can be applied more effectively to containers. If we can reprogram our architect brains a bit, we can apply a lot of what we know today to containers.
Let’s start by thinking about the control points that we have in a containerized environment. There are three main components to a production container environment. We can control information flow at each layer.
The three layers of a container environment.
Containers/Images
Working from the center, we begin with the container images themselves. Container images are made up of:
- Operating System Binaries
- Operating System Libraries
- Language Runtimes (Java, PHP, Ruby)
- Middleware (Message Busses, Application Servers)
- Databases, Datastores
- Developer Code
Our current operating model controls the flow of this type of content already with physical servers and virtual servers, and it’s actually just as easy to apply to container images. We can utilize and apply techniques such as:
- Trusted Content (What’s in the container matters. Don’t install from hackme.com.)
- Content Provenance (Track who changed what.)
- Security Scans
- Remediation/Patching
- Bill of Materials
- CVE Databases
- Security Response Teams
- Limit Root Access (Don’t oversell User Namespaces.)
- Limit User Access (Who controls content.)
Containers add the ability to easily apply techniques such as:
- Bill of Materials
- Signing
- Read-only Containers (Read-only servers were popular in the late 90s.)
- Atomic diff/Docker diff to see what changed in a container.
Container Hosts
Moving out a ring, to the container host. Many of these techniques, we apply today.
- Kernel Quality
- Capabilities
- Read Only Images
- Limiting ssh access (root access and users)
- Well understood/controlled configuration (cloud-init, Ansible)
- Tenancy
Since containers are just fancy processes with a well-controlled user space, it’s easier to apply techniques like:
Container Platform
The container platform layer is where we want to control access for end users and even administrators where possible. This layer exists in the world of physical and virtual servers but is typically an administrator only tool, such as vCenter or HPSA. In the world of containers, it’s much more common to delegate some access to developers, architects, and application owners.
- Role-Based Authorization
- Authentication (LDAP, network level access/restriction to the platform)
- Environment Isolation (development, testing, production)
- User Demarcation (kubectl exec)
- Network Separation
- Key Management
Conclusion
Much of what we know today about information assurance and computer security can be applied in a containerized environment. Some security techniques (read-only servers, tripwire, etc) that we tried before were difficult to use with virtual machines but are made easier with containers. Containers don’t contain, but good technical controls can make containers even more secure than regular processes — information assurance techniques need to be thoughtfully applied in layers.
Come join me at Software Circus and let’s talk about container defense in depth. I am going elaborate on the above concepts with the goal of attendees walking away with the ability to apply these information assurance techniques in their own environments.
Docker and Red Hat are sponsors of The New Stack.
Feature image by Aron Van de Pol, via Unsplash.