LinuxKit: What and Why
Let’s start with the what and why of LinuxKit.
As you might expect, the LinuxKit story starts with Docker itself. Docker, of course, was originally designed to sit on top of the Linux kernel, and to make heavy use of Linux resources. It was from the start basically a system for virtualizing and abstracting those underlying resources.
Docker got its start not just as a container system, but also as a Linux container system. Since then, Docker has developed versions of its container management systems for other platforms, including widely used cloud service providers, as well as Windows and the Macintosh OS. Many of these platforms, however, either have considerable variation in the Linux features which are available, or do not natively supply a full set of Linux resources.
This makes it difficult to provide a standardized environment for cross-platform Docker deployments. If containers deployed on Windows, the Mac OS, or a cloud platform cannot count on standard system resources being available without special platform-specific provisions being made, the usefulness of Docker on those platforms may be limited.
Bridging the Gap
LinuxKit is Docker’s attempt to bridge that deployment gap by providing a standard package of Linux system resources for all platforms where they may not be available. Working in partnership with the Linux Foundation and several major Linux stakeholders, Docker has placed a lean (35MB) but functional Linux distribution (based on the already lean Alpine) into a set of containers, using the Moby container assembly framework.
It is highly modular and configurable. You can deploy only the services and related dependencies that you need. At the same time, it provides sufficient resources to give you standardized Linux functionality while running Docker on a non-Linux platform.
A Standard, Cross-Platform Set of Resources
LinuxKit is not, of course, the only method for deploying containers with Linux resources on non-Linux platforms. Cloud platforms generally include a rich container ecosystem, and even Windows has extended its container and Linux-related capabilities significantly with HyperV and the Bash shell.
But LinuxKit does provide a standardized, cross-platform Linux environment for container-based applications, potentially eliminating (or at least greatly reducing) the need for container- or application-level modifications when moving from one platform to another. Cross-platform deployment without modification (or with changes only to the YAML configuration file) could allow Docker containers to move into environments where they do not currently have a strong presence.
LinuxKit and Security
How does LinuxKit stack up in terms of security?
In many ways, a high degree of security is built into its fundamental design:
• LinuxKit is lean. It includes the features and services necessary to support container deployment of Linux-based applications, but overall, it is stripped down to necessities, providing a much smaller attack surface than a typical Linux deployment.
• LinuxKit is containerized. All LinuxKit resources are encapsulated within containers, further reducing the attack surface, and adding extra insulation between your containerized application and underlying system resources.
• LinuxKit is modular. You only deploy the resources that you need. The resources that you don’t deploy simply aren’t present, and are thus unavailable for attack.
Modularity as Security
Let’s take a closer look at that last point. Since containers were first introduced, a major security concern has been the container’s relationship to underlying system resources. A virtual machine contains the operating system on which the application runs, so its encapsulation is, if not complete, as close to complete as one is likely to come. To many people who were used to the built-in security provided by VMs—containers, with their more-or-less direct use of resources from the underlying OS, seemed risky by comparison.
Since then, of course, Docker and other container deployment and management services have added security features which address most of the early concerns. The fact remains, however, that containers are designed to make use of the underlying platform’s resources, and are thus less encapsulated than VMs.
In some ways, LinuxKit represents a move toward the greater degree of encapsulation represented by VMs. To the degree that it places the OS in the container, it removes at least some of the need for the application to access underlying system resources. Depending on the nature of the underlying platform, and on the resources which the developer includes in the LinuxKit deployment, LinuxKit could provide a degree of encapsulation at least approaching that of a virtual machine.
The portability of LinuxKit is also reminiscent of virtual machines. The mere fact that it is designed to be portable minimizes its interactions with the host OS, increasing its encapsulation. This portability also means that a potential attacker cannot count on a specific host OS being present. An Ubuntu-specific exploit is likely to be useless against a Windows-based LinuxKit deployment.
This opens up the possibility of using heterogeneous platforms for added security. If a LinuxKit-based application is running on several different host OSes, an attack based on exploiting the features of one OS is likely to leave the others untouched. This also means that if a serious infrastructure-level outage were to take out an application’s main platform (for example, a major cloud provider), it might be relatively easy to quickly switch to a backup based on another platform (or even local servers) until the main deployment is restored.
General Security Issues
Are there other security considerations? Theoretically, the standardization built into LinuxKit itself provides a possible set of attack surfaces. A vulnerability within the LinuxKit OS (or the underlying LinuxKit deployment tool) might make it possible to attack a LinuxKit-based application regardless of the host OS.
The modularity of LinuxKit, however, makes this approach more difficult, since a potential attacker cannot count on a given resource, beyond the kernel and a handful of other basic features being present. Needless to say, this is also where a comprehensive container security suite such as Twistlock comes in, since unified management of container-based application security is an absolute necessity in today’s world.
The bottom line? LinuxKit’s built-in/structural security features and VM-like encapsulation may make it worth considering even where portability and cross-platform deployment are not major considerations. Docker was built for portability, but the main draw may turn out to be security after all.
Want more resources on securing Docker? Visit our Resources Center for container security videos, white papers, and more. Or contact us for a demo to see what Twistlock can do for your organization.
Related LinuxKit & Docker Security Posts
Follow us on Twitter
Follow us on Twitter for real time updates on the cloud native ecosystem, Twistlock product, and cloud native security threats.
How to Lock Down the Kernel to Secure the Container HostRead the Blog
One Chapter Ends, Another BeginsRead the Blog
The Greatest Security Risks Lurking in Your CI/CD PipelineRead the Blog
Cloud Platform Radar: Powerful Cloud Asset IdentificationRead the Blog
Securing Serverless Functions: Visibility with Serverless RadarRead the Blog