Twistlock and the Future of Container Security

Twistlock is a new company aiming to solve one of the biggest issues in container-based application development today: security.

As container platforms like Docker, Kubernetes, Mesos, Diego and Garden all continue to evolve, the need for clearly defined software policies that are universal in scope is crucial. Container security is a hot area of interest for investment, as Steve Herrod, Managing Director at venture capital firm General Catalyst, told The New Stack at AWS Re:Invent conference earlier this month. He talked about the emerging possibilities for those working in container security.

Twistlock is one of those companies on the cutting edge of container security, and it’s getting noticed; at least six different organizations are using Twistlock to secure production systems.

What Is Twistlock?

At its most basic, Twistlock is a rule-based access control policy system for Docker and Kubernetes containers. Twistlock is able to be fully integrated within Docker, with out-of-the-box security policies that are ready to use.

Security policies can set the conditions for users to, say, create new containers but not delete them; or, they can launch containers but aren’t allowed to push code to them. Twistlock features the same policy management rules as those on Kubernetes, wherein a user can modify management policies but cannot delete them.

Twistlock also handles image scanning. Users can scan an entire container image, including any packaged Docker application or Node.js component. Twistlock has done its due-diligence in this area, correlating with Red Hat and Mirantis to ensure no container is left vulnerable while a scan is running.

Twistlock also deals with image scanning of containers within the registries themselves. In runtime environments, Twistlock features a Docker proxy running on the same server with an application’s other containers. This is essentially traffic filtering, whereupon the application container calling the Docker daemon is then re-routed through Twistlock. This approach enforces access control, allowing for safer configuration where no containers are set to run as root. It’s also able to SSH into an instance, for example. In order to delve into these layers of security, Twistlock enforces the policy at runtime.

Solving Pain Points with Better Security

As Twistlock is a new company, it is still testing out its technology on large-scale deployments. Currently, the largest deployment in production is running a few hundred servers without issues. Twistlock engineers state that one server should be able to handle 15-20,000 servers, but still has to verify this.

Additionally, Twistlock has heard concerns regarding DevOps and IT security teams needing better visibility into containers. Throughout its work, the company has found that people don’t know what security policies to write for today’s container-based technology.

Given that container technology is still relatively new (or at least changing), no one has written a policy which can be universally defined as the standard for enforcing security practices when working with containers. Docker offers a set of best practices that Twistlock has adapted to address 58 of the 60 issues affecting those working on Docker and containers with its platform. Containers use a vastly different layer of abstraction than what most IT professionals are accustomed to. Organizations may have security policies that speak to specific levels of security, but they get lost in translation when attempting to re-format their needs for a container-based pipeline.

Twistlock’s methodology to define its out-of-the-box security policies start with modifying the Docker best practices, pared down to policies that could be successfully written. It is not quite an interface, though it shares similarities with the concept. People often say they understand basic container security concepts, but Chenxi Wang, Chief Strategy Officer at Twistlock, raises the question, “do customers have a sophisticated view on customer-facing vs. back end containers? They may have a configuration in mind, but not the security segregation.”

Twistlock has the proficiency to articulate a policy on a user-by-user basis, working with customers to customize container security solutions that work for their particular use cases.

Container Security Moving Forward

The requirements for working within Twistlock are heavily based on continuous integration. When new code is written in images, it is then integrated into the Twistlock API to push an event, whereupon the new image is deposited into the registry along with its unique IDs. It is then pulled out by Twistlock and scanned to ensure it complies with the set security policies in place. Twistlock deposits the scan result into the CI process so that developers can view the result for debugging purposes.

This scan doesn’t slow down in runtime, though Twistlock notes that it could eventually be a latency issue. The company has set constraints on how much memory/CPU power its services can use, which prevents potential system bottlenecks. If a server were to reach capacity, Twistlock would alert a system admin to move containers off to a new server.

Docker is Twistlock’s current focus. In fact, Twistlock was written in Go, primarily because of the focus the company has within the Go-driven Docker ecosystem. Pantheon was running containers before Docker came along on Linux, and if TwistLock can scale to Pantheon’s capacity, the company would be open to working with that technology as well, Wang noted.

Collecting accurate metadata is critical for Twistlock’s evolution, as it will pave the way for Twistlock to continue to refine and introduce new out-of-the-box security policies for varying customer use cases. In addition, it will help to refine how Twistlock allows customers to set their own security policies moving forward.

The company continues to get people talking about OpenStack and Mirantis. Collecting metadata, however, is a gigantic task, as there is a large number of sources to draw from, all of which will be crucial for enforcing security policies. They will be used not only to build extensive vulnerability resources, policy improvements and access control, but to enforce two-factor authentication at admin points, and add to other features that ensure containers are secure at every stage of development.

Continually evolving the policies around container security will be essential until a universal set of policy regulations is adopted, one with clear instructions as to how to enforce policy across a multitude of use cases. This work will be one of the most pressing issues for those working within this ever-changing technology stack.