Container Defense in Depth

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

Scott McCarty

At Red Hat, Scott McCarty helps to educate IT professionals, customers, and partners on all aspects of linux containers, from organizational transformation to technical implementation, and works to advance Red Hat's go-to-market strategy around containers and related technologies. He also liaises with engineering teams, both at the product and upstream project level, to help drive innovation by using feedback from Red Hat customers and partners as drivers to enhance and tailor container features and capabilities for the real world of enterprise IT.

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:

SECCOMP sVirt Hardening: NO_NEW_PRIVS, Read Only Images, cap-drop=ALL, user=user 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 serversbut 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 machinesbut 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 imageby Aron Van de Pol , via Unsplash.