Securing and monitoring containers in enterprise environments
All Boxed Up

© Lead Image © Franck Boston, Fotolia.com
A recent flurry of activity in the container space raises several interesting questions about security among a number of operational aspects in the enterprise environment.
Docker doubtlessly still reigns supreme in the container run-time space, but various industry projects mean that the Docker stronghold will almost certainly shift in one form or another over the coming months. The recent release of Docker Enterprise Edition (Docker EE) [1] shows that this fact hasn't escaped Docker, and to my mind, they should quite rightly take advantage of their market share and fully monetize their current standing.
The Docker EE offering advises you to meld all parts of your containerization and orchestration workflow together using one vendor to avoid sticking pieces of duct tape between the components to integrate them. In their words: "An application-centric platform, Docker EE is designed [to] accelerate and secure across the entire software supply chain, from development to production running on any infrastructure" [1]. More easily digestible details can be seen in Figure 1.
Just One Moment
My interest from a DevSecOps perspective is security, and in Figure 1 you can see that image scanning for common vulnerabilities and exposures (CVEs) [2] is indeed bundled with the EE flavor of Docker. However, that is not so for the less feature filled Docker Community Edition (Docker CE) [3], which is promoted for developers and small teams. However, it is thankfully available for free as a preview for a period and for those using a paid plan for private repositories. As you can see in Figure 2, it's highly efficacious.
The Docker site states: "During the free period, Docker Security Scanning scans the three most recently updated tags in each of your private repositories. You can push an update to an older tag to trigger a scan. The scan runs on each new image push and updates the scan results when new information comes in from the CVE databases" [4].
Although this functionality is undoubtedly very much required, unfortunately, it's merely one critical aspect of securing your containers, and you might be forgiven for falling into a false sense of security.
Not Quite as Simple as That
Although I have no doubt that Docker EE offers a sophisticated security posture using a greater refined set of security principles, such as verifying images have come from a trusted registry (and not an unknown registry populated with a selection of images with nefarious intent), those businesses feeling satisfied that all their bases are covered by just running CVE scans are definitely missing a trick.
In simple terms, the three major areas to worry about when securing your containers and continuous integration/continuous deployment (CI/CD) pipelines are as follows:
- Images. It's imperative that images are signed so that you know precisely which version of an image you are pulling from your trusted registry (with which you are authenticating and methodically logging each transaction). Once you know what you're dealing with, you can scan that image for common vulnerabilities across multiple third-party feeds.
- Run Time. Another critical area is your container run-time security. For example, what if a container suddenly spawns an anomalous process or tries to create a volume mount when it has never tried to do that in the past? Monitoring these changes and automatically mitigating the level of damage that they can cause or alerting on-call staff to any such changes should they occur in production makes running an estate reliably much easier.
- Host Security. A third aspect often overlooked is access to the run-time daemon itself, which integrates into the host's kernel with impunity. Take the popular Docker
run
command as a case in point. Think of a Jenkins job firing adocker run
– the daemon acts as the superuser, the root user, on the host. Even the suggested Docker system group offers no protection because any access to the Docker daemon is effectively relinquishing superuser permissions on the host. The terrifying result of a successful, sophisticated compromise is that you would lose all the containers on that host followed by the host itself.
Approaching your container security from a traditional security perspective for a moment, remember that effective mitigation is all about layering your protection; providing defense-in-depth.
There is some solace in that containers are declarative. In other words, a Dockerfile might be treated as a shipping manifest of sorts (pun intended).
You can use that predefined shipping manifest to describe how a container should work and, following that, how it was intended to interact with your estate. With some forethought, you can translate this key information into a useful ruleset.
Thankfully, inside containers, developers mostly use popular software components, so these rulesets can be relevant to many decoupled containers, and it can be much easier to define those that might have been required for old-school bare metal servers running many different services simultaneously.
Clearly, a number of security challenges are introduced by running containers. However, undoubtedly, modern containers are fantastic for deploying software. Containers have been fully embraced by developers because of their ease of use, hence the unparalleled popularity across the industry relative to that of former technologies used in containers. That said, one fact has been repeated that cannot be denied …
Containers Are Not Virtual Machines
For good reason, developers love containers for the convenience of packaging dependencies together into a portable unit. However, not unsurprisingly, they commonly expect containers to work like virtual machines (VMs) from a security standpoint. This is definitely not helpful to either party because they are distinctly different animals.
As vigilant security becomes increasingly important in this brave new containerized world, you need to accept that applications will always be compromised, and you therefore need a way of defending against these threats.
After all, containers are not like Solaris Zones or BSD Jails from the past, which are relatively prebuilt and uniformly defined. Modern containers are instead made up of a collection of configs that the Linux kernel has successfully made available over recent years. Their configuration is not set in stone, which makes them more flexible; of course, this complexity adds other security challenges.
Behind the scenes, containers now comprise namespaces and control groups (cgroups), which are kernel primitives, or the system's Lego blocks, from which you build upward.
Kernel namespaces offer a running process a defined amount of visibility of a system (e.g., a specifically grouped set of other processes or a local routing table of its own). Separately, control groups offer a sys admin granular control over what that process can use.
Consider that namespaces are just a simple form of virtualizing system resources, and cgroups simply control, for example, how much CPU or RAM a process can use.
By combining the functionality of namespaces and cgroups, you can build a type of isolation between your containers and host (and indeed intracontainer isolation), but you certainly need to provide additional hardening on top, such as a Mandatory Access Control (MAC) system (e.g., SELinux on Red Hat derivatives or AppArmor on Ubuntu and Debian). It's no understatement to say that Red Hat has put a lot of effort into SELinux for containers, and for good reason.
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.
News
-
PipeWire 1.0 Officially Released
PipeWire was created to take the place of the oft-troubled PulseAudio and has finally reached the 1.0 status as a major update with plenty of improvements and the usual bug fixes.
-
Rocky Linux 9.3 is Available for Download
The latest version of the RHEL alternative is now available and brings back cloud and container images for ppc64le along with plenty of new features and fixes.
-
Ubuntu Budgie Shifts How to Tackle Wayland
Ubuntu Budgie has yet to make the switch to Wayland but with a change in approaches, they're finally on track to making it happen.
-
TUXEDO's New Ultraportable Linux Workstation Released
The TUXEDO Pulse 14 blends portability with power, thanks to the AMD Ryzen 7 7840HS CPU.
-
AlmaLinux Will No Longer Be "Just Another RHEL Clone"
With the release of AlmaLinux 9.3, the distribution will be built entirely from upstream sources.
-
elementary OS 8 Has a Big Surprise in Store
When elementary OS 8 finally arrives, it will not only be based on Ubuntu 24.04 but it will also default to Wayland for better performance and security.
-
OpenELA Releases Enterprise Linux Source Code
With Red Hat restricting the source for RHEL, it was only a matter of time before those who depended on that source struck out on their own.
-
StripedFly Malware Hiding in Plain Sight as a Cryptocurrency Miner
A rather deceptive piece of malware has infected 1 million Windows and Linux hosts since 2017.
-
Experimental Wayland Support Planned for Linux Mint 21.3
As with most Linux distributions, the migration to Wayland is in full force. While some distributions have already made the move, Linux Mint has been a bit slower to do so.
-
Window Maker Live 0.96.0-0 Released
If you're a fan of the Window Maker window manager, there's a new official release of the Linux distribution that champions the old-school user interface.