Announcing Twistlock 2.4

We just signed off on Twistlock 2.4, the 13th time we’ve shipped a major release of Twistlock over the past 3 years. A few other fun facts from GitHub: we’ve worked on more than 7500 issues, pushed more than 4700 commits, built Twistlock more than 750 times, and shipped 311 customer requested features for well over 100 enterprise customers during that time!

— the Twistlock R&D and product teams
Herzeliya and Baton Rouge

Infinite scale and multi-tenancy with Projects

As container adoption grows, our customers are both scaling their deployments and sharing them across multiple business units. We have some customers with >10,000 hosts running containers so it’s critical that we ensure Twistlock scales to these very large environments. At the same time, many customers need to compartmentalize their deployments for regulatory or operational reasons and we don’t want them to have to manage many different Consoles to do so. In 2.4, we’re introducing Projects to address both of these scenarios with a simple, scalable architecture and a familiar user experience.

Projects enable customers to have a single central Console, with a single URL, that can then scale out infinitely while sharing the same configuration and rules or be compartmentalized into multiple tenants each of which operates independently. For example, you might have https://console.customer.com as the single URL for accessing the Console UI and API, but have different Projects to scale out across each of your datacenter regions, or separate them by business units, or whatever other organizational boundaries you need to maintain.

There are two type of Projects in Twistlock and a single Console can support both of them simultaneously. Scale Projects inherit the rules and configuration defined centrally and allow you to scale out your Twistlock deployment in units of 1000 Defenders per Project. Users and groups are assigned RBAC roles centrally to Tenant Projects, but each Tenant Project then operates independently, with its own unique rules and configuration. When a user logons to Twistlock, they’re shown a list of the Projects they have access to and can change between these Projects at any point in the UI without losing their place.

Linux and Windows Server VM Defenders

As we discussed in our recent Continuum of Cloud Native Topologies piece, while containers are the predominant way to deploy modern apps, most customers still have some workloads that run directly on VMs, not within containers. For example, you may choose to run your databases in VMs because you’re more comfortable with the tooling, have better vendor support, or just because they’re already there and working! We’ve had a number of customers tell us they’d love to see Twistlock handle these scenarios and in 2.4 we’re delivering Defender for Linux and Windows Servers to do so.

These Defenders have the same capabilities as when Defender is running within a container (indeed, they’re literally the same bits), but are deployed as a systemd or Windows service, rather than run within a container. We optimized the deployment flow for automation, so you’ll find the experience of deploying them very comfortable if you’re using tools like Chef, Puppet, or Ansible to automate host management. Of course, you can also directly deploy them from the Console UI as well.

Linux Defenders provide runtime defense, vulnerability management, compliance, and access capabilities while Windows Server Defenders in 2.4 focus on vulnerability management, with the rest of the features coming later this year. Because we’ve long supported host protection from our containerized Defenders, these new deployment options don’t change the UI much, and simply show up alongside your existing, container running, hosts we’re already protecting.

Host runtime v2

We introduced host runtime defense capabilities in Twistlock 2.1, using the same machine learning powered, model based, approach that we do for containers. We’ve continued to tune our approach and in 2.4 host runtime defense takes a major step forward. In previous releases, host runtime focused on modeling the process activity of system services. While effective for containers which are more minimal and predictable, this approach is somewhat primitive for hosts which have a far larger surface area and are typically managed as stateful entities.

In 2.4, we continue to prioritize automatic modeling of system service behavior but add an additional layer of abstraction to the model beyond processes. Specifically, we introduce the notion of ‘capabilities’, which are curated sets of process and file system actions defined by our Twistlock Labs research team. These capabilities provide greater predictive accuracy for a given service’s model because they don’t rely exclusively on observed activity but instead use those observations to infer likey additional activities that may have not yet been observed. For example, if Twistlock observes a service executes useradd we can infer that it manages user accounts, assign it the users capability, and thus have a complete, tightly defined, set of file system and process knowledge associated with it. This approach allows us to more precisely model the actual activity of background services, resulting in more comprehensive preventive runtime defense while also demonstrating lower false positive rates.

Multiple registry scanners

Scanning images in registries continues to be an important and frequently used technique to identify vulnerability and compliance problems before they impact production. Historically, Twistlock has used a single Defender to scan all the registries and repositories in a given environment. While effective, this approach could be limiting to organizations with multiple registries dispersed geographically over lower bandwidth links, very large registries with tens of thousands of images, or registries in isolated networks.

In 2.4, we’re adding the ability to have multiple registry scanners, simply configured per row in the registry configuration page. This simple configuration allows you to specify exactly what Defender will scan a given registry or repository and any and all Defenders can be registry scanners simultaneously. For example, if you use both AWS and an on-premises datacenter, each with its own registry, you may have a Defender in your AWS environment scan your ECR registry, while a Defender in your local environment scans your Docker registry. Because this configuration is on a per-row basis, you can also use it to multiplex scanning of the same registry across multiple Defenders simultaneously.

Time based vulnerability blocking

Twistlock’s Jenkins plugin has always provided not just visibility about vulnerability and compliance risk, but also controls to actively prevent risky images from progressing down the pipeline. For example, you can configure the plugin to fail builds with medium severity vulnerabilities. In most organizations, developers can’t simply incorporate every update immediately after it’s released. We’ve all dealt with regressions and other unforeseen problems with updates so dev teams usually need some time to test updates before integrating them. While this possible to do today, it’s a manual process where the security team needs to add a CVE to Twistlock’s allow list until the dev team tests it, then remember to remove it afterwards.

In 2.4, we’re making this flow completely automatic. Most organizations have an approach that defines some kind of grace period for teams to be able to test updates before integrating them. For example, you might say your developers have 30 days after an update is released to patch their images. In 2.4, we make this policy a configurable option on each build job and show the countdown timer directly in the build output in Jenkins.

For example, assume your timer is set to 30 days. The first day a developer builds a vulnerable image after an update is available, they’ll get a warning that if they don’t update the component within 30 days, the build will be blocked. The next day, they’ll be warned they have 29 days left, and so on until the grace period expires and the build is blocked. The key benefit here is that once the security team sets the policy, everything else happens automatically and no one needs to manually add or remove entries from an allow list. Instead, Twistlock manages the entire flow based on the vulnerability data we’re already distributing through the Intelligence Stream.

CNNF for Windows

Over the past few months, we’ve started to see more customers using Windows Containers. Twistlock has long supported Windows and, in 2.4, we’re adding beta support for an often requested feature: our Cloud Native Network Firewall. CNNF is a layer 3 firewall that compartmentalizes containers and applies a least privilege networking model to inter-container traffic. For example, if your front end microservice is compromised, it shouldn’t be able to port scan the environment nor connect directly to the container running your data persistence microservice; it should only be able to talk specifically to the other front end microservices it normally communicates with. CNNF ensures that only these specific ports and destinations are allowed, limiting the blast radius of a compromise.

In 2.4, CNNF is available in beta for Windows, allowing you to apply these same kinds of network controls to your Windows containers. For example, you can ensure your IIS store front containers are only able to talk HTTPS to your ASP.NET shopping cart microservice, which can only talk to your SQL Server containers. CNNF will enforce this traffic model and block any unexpected communications. CNNF is cross platform, and can enforce this connectivity mesh even amongst mixed Linux and Windows containers.

Support for Open Container Technologies

While the Docker project was a trailblazer for container technology, the ecosystem has grown significantly over the past few years. New projects like runC and containerd provide open standards for running and managing containers and some of our customers and partners are targeting these technologies for future projects. Kubernetes 1.5 also introduced the Container Runtime Interface as a pluggable layer to enable easy integration with other runtime technologies which led to the CRI-O and CRI-containerd projects. Prior to 2.4, Twistlock was tightly coupled to Docker itself which limited our ability to protect environments built on these new technologies but all that changes now.

In 2.4, Twistlock integrates directly at the runC and containerd layers meaning we can now protect any environment and stack built around these open technologies. We’ve already tested flavors like ‘pure’ runC, Docker built around runC (as has been the case since Docker 1.11), and Kubernetes focused runtimes including CRI-O. Because these are open standards and we’ve focused on integration at the lowest layers of the stack, we should ‘just work’ with any future technology built around them too. The best part is that there’s no work you have to do as a customer to take advantage of this. Defender automatically detects the kind of stack it’s running on and configures itself appropriately. You can even have a single Twistlock Console managing a mix of multiple Defender types simultaneously, without any special configuration required!

← Back to All Posts Next Post →