In the beginning there was lxc… or maybe Solaris Zones, or BSD Jails… it’s complicated. One thing that is clear, though, is that containers became truly mainstream with the Docker project. Like most great technical innovations, Docker stood on the shoulders of older giants but with a new focus that addressed a market need at exactly the right time. In Docker’s case it was a focus on developer experience and ease of (re)use that took containers from a fairly arcane infrastructure technology into something truly transformational. As containers exploded in popularity, deployed footprint, and technical capability, users began requiring more sophisticated management and deployment tooling which led to orchestrators like Kubernetes and Swarm.At the same time, came a desire to have an open approach to core container technologies such that they’d be built around standards not controlled by any single company. Docker themselves made significant contributions to this openness through the Moby Project.
Understanding the Docker stack
Docker’s Moby contribution was significant because it effectively decomposed the Docker project into a set of discrete open source projects (in the Unix philosophy of doing just one thing really well). This decomposition included all key components, allowing others to reuse just the specific parts of the Docker stack needed for their particular use cases. At the core of these stacks is runc, the (mostly) universal tool for spawning and running containers that conforms with the Open Container Initiative runtime spec. Often, but not always, containers that are started and run by runc are managed by containerd. Modern versions of Docker itself use these components, in a layered manner, such that dockerd is a designed as a friendly user experience layer that calls into containerd for managing containers, which in turn relies on runc for starting and running them.
When we were first starting with Twistlock, Docker was the only runtime used by customers in any significant manner. Accordingly, that was the layer where we integrated with the stack. Even today, such an integration point would be useful to the great majority of real world customers we see.
Support for newer container runtimes
Over the past couple of years, though, as the world has largely settled on Kubernetes as the de-facto standard orchestrator, Kubernetes users have wanted greater flexibility in the runtime layer that they’re using it to manage. To support these innovations, Kubernetes introduced the Container Runtime Interface as an abstraction layer between the orchestrator and the runtime, such users can swap out Docker for other CRI compliant runtimes for host level container management. The most popular of these projects today are cri-o and cri-containerd.
We’ve always had the philosophy of being everywhere our customers are going, which is why when we shipped Twistlock 2.4 in March, we re-architected our integration to go lower in the stack. Now, rather than being dependent upon dockerd, Twistlock integrates at the most universal place possible: runc. Regardless of what upper level construct you happen to be using, from containerd with Docker Engine and Swarm to cri-o with Kubernetes, even to technologies yet to be invented that will leverage runc, Twistlock provides the same comprehensive set of protections we always have. For example, if you want to prevent images with critical vulnerabilities from running on your CRI-O powered cluster, we have you covered. If you need advanced threat protection for your apps running in Docker Swarm, we’ll take care of you. And if you want to roll your own OCI compliant stack around runc in your spare time, we’ll help protect you there too.
We’ve also focused on making the whole experience ‘just work’. There’s literally nothing special you need to do within Twistlock to configure our Defenders differently between stacks. You simply deploy Defender as you always have, such as in a DaemonSet or Swarm Global Service, and Defender detects what kind of environment it’s in and configures itself appropriately. Because all our features work universally across runtimes, there’s no complexity in your policy configuration nor need to exempt certain resources. This also enables a completely heterogeneous environment – a single Twistlock Console (or one of the multi-tenant Projects it may manage) can protect a diverse set of stacks simultaneously, such as some clusters running Swarm, some using ‘normal’ Kubernetes or OpenShift, and others running on CRI-O.
Follow us on Twitter
Keep up to date with the latest news from TwistlockLabs and TwistlockTeam.
6 Tips for Secure Data Management for Containers
One of the main reasons why containers have become so popular is that ...
OpenShift Internal Registry: Populating Registry Scans with Twistlock
Twistlock uses the Docker v2 Registry catalog API call to inventory im...
Better Together: Protecting Docker Registries with Twistlock and JFrog Artifactory
In a containerized devops lifecycle, a registry such as JFrog Artifact...
Twistlock Jenkins Plugin and Time-Based Vulnerability Blocking : 2.4 Deep Dive
Twistlock has provided the ability to seamlessly integrate security in...
Securing Containers on Red Hat OpenShift: Twistlock Deployment Script
Booz Allen Hamilton has been an invaluable partner since the early day...