Part 1 of this series examined the emergence of Docker and how it owes a nod to several different schools of thought about how to group processes together and make them do work, without easily getting out of control. In Part 2 we take a look at some of the Docker container security concerns that have grown along with the platform's popularity.
Indeed, the increasing use of continuous integration (CI) programming models intersected with Docker handily, and Docker popularity soared. Today, there are hundreds of thousands of available Docker images circulating in Docker’s own “official” repositories. And therein lies the crux of the biggest problem in Docker container security: image/configuration integrity.
Integrity is a direct function of provenance and the assurance that images have been patched/fixed/updated. Although runtime behavior monitoring is important (and there are both methods and container platform-specific products that do this), Docker images still have enough flexibility to work or die miserable deaths. In the worst case, a repository may be compromised--intentionally or not.
Recently, 17 varying Docker images were found to contain either reverse shells, security key grabbers and/or Monero cryptomining-infected images. These images were pulled from repositories. In each case, there were ways to detect issues and to confine Docker and a managed container fleet from problems, but it takes extra processing to do this.
Image Security Is Paramount
Docker ostensibly finds image problems by parsing images, but this is offered by Docker only as an enterprise-level service. Many third-party container security software offerings also do this, and other repositories and registries may or may not parse images for malware or misconfiguration.
How can things go wrong? Actual malware presence is one way, certainly, but there are ways to misconfigure images and open them up to tampering while in production. One way is to use misconfigured configuration files. An example would be to allow root SSH logon with a known set of pre-provisioned keys. This is a configuration file problem, but also a way that a few developers like to get in to their preproduction images. Random image repositories should be considered lethal, but even “official” repositories are not vetted in certainty and may become moldy. It’s a matter of trust. (See "zero trust models," below.)
Then there are problems with patching and fixing, along with needed updates to the image source files--and the host where Docker resides. Queries and updates can often be accommodated with tools that developers already use, including Kubernetes or Mesos control planes. Puppet, Chef and even Jenkins can be configured to manage and assay container fleets, even while in production and past the development phase. Querying Docker for its image components and status is a well-known drill.
Least-Trust to Zero-Trust Models Are Preferred
Docker, as mentioned in Part 1 of this series, runs as a root process to demote user privilege and storage accessibility to a minimum. As low-ranking objects, containers are vulnerable across the range of other objects that are connected to them--generally by networking, but also by storage.
For this reason, there are two vectors of privilege: one in the administrative plane, where containers are spun up into working organisms, and another plane, where the mounted containers must talk to each other to function as a workload unit. Trust follows a chain of authorities and known states, and it’s up to each organization deploying (modified) Docker constructs to be able to attest to states by looking themselves. Without that kind of rigor, shenanigans ensue, regulatory compliance is jeopardized, and frameworks crumble.
Administrative trust must be tightly controlled to prevent known and/or unknown hands from making changes to images. (Sometimes changes are made to cover mistakes, and sometimes they inject Monero Miners into images.)
Zero trust models involve, at minimum, a secure/encrypted channel between and among production elements, which also implies a degree of security encryption keys, key management, and links to the administrative plane described above. Some organizations also use policy elements regarding levels or degrees of authority with regard to changing networking, storage, elemental component, and/or container revisioning to match workload needs.
Absolute Networking Control With Authentication/Verification
You won’t see Monero hashes leaving your container fleet if you aren’t looking for them. Containing the containers means asserting absolute control over network traffic destinations both on the container host and within container infrastructures, including container object instances that talk to other container object instances. It takes only a route to the Internet to cash in the Monero chips or to disrupt, pester or attempt to undermine container fleet networking communications and infrastructure.
This involves a consistent model of infrastructure designed around workload needs to communicate. Just because a system is highly demoted doesn’t mean it doesn’t have communications needs (with accommodations for fluidity as well as implementation of a well-planned architectural model).
Software-defined networks are easy to spin up, and, by using admittance controls, can contain traffic well when properly configured and maintained. Using Kubernetes, Mesos and other control planes usually still involves actively asserted port controls within containers to make sure traffic will be headed exactly where it’s desired. Hosts may also need to be monitored for odd traffic and policy violations.
Further monitoring of container traffic leads to detection of anomalous traffic or undesired presence of traffic. Monitoring traffic flows for strange behaviors becomes the crux of products like Twistlock, AquaSecurity and Zscaler. Third-party management apps for container workloads may have a variety of policy assertions available and, with luck, the capacity to sniff traffic to find, for example, the scent of freshly minted "coins" being made where they weren’t desired.
Stay tuned for Part 3 of this series.
