We’re excited to officially announce the release of Twistlock 2.0, our 9th major release, generally available today.
We’ve highlighted some of Twistlock 2.0’s flagship features over the past week – but that’s just the beginning. Twistlock 2.0 is a milestone release, with a completely refreshed UI, major new features, and backend ported from Node to Go for significant performance improvements.
Twistlock 2.0 Key Features
- Runtime Radar 2.0
- Compliance Explorer
- Jenkins Pipeline Support
- Certificate Authentication
- Run Console in the Cluster
- Embedded Secret Detection and Blocking
- File Integrity Monitoring
- Moving from Node to Go
When we originally shipped Runtime Radar, our goal was to provide a way to easily visualize your environment in a way tailored to containers. Traditional tools are often IP centric which doesn’t really make sense in a container deployment in which connectivity and addressing is largely virtualized and ephemeral. In Twistlock 2.0, we’re delivering on this goal with 3 core capabilities.
First, we take a container centric approach to modeling and drawing connectivity between entities, that’s based on entities like pods and services, not hosts and static IPs. This means that the connectivity and entities you see are aligned with the way you’re actually running your apps.
Second, we’re pulling in much more data now with color coded overlays of vulnerability and compliance state and information on the orchestration platforms in use. So in Twistlock 2.0, in one view you can not only understand how entities communicate but also their risk state. Here’s an example of what that looks like for the Kubernetes Sock Shop sample app:
Finally, and most powerfully, Runtime Radar now allows you to export the entire connectivity topology, both what we’ve learned and what you’ve added, into a Kubernetes networking policy that’s then enforced by networking plugins like Weave and Calico. This is provides an additional layer of defense in depth to the segmentation we already provide between entities at runtime.
Many of our customers are large enterprises and government agencies with demanding compliance needs. These organizations need to not just be able to check compliance state at a point in time but to actively enforce it, in a policy driven manner, across their entire environment. Twistlock’s compliance features have always allowed customers to monitor and enforce all ~90 Docker CIS Benchmark settings, as well as checks we’ve built ourselves (such as for embedded secrets), as well as customers’ own custom compliance settings via our XCCDF support. In Twistlock 2.0, though, we’ve added a completely new way to understand your compliance over time with Compliance Explorer.
Compliance Explorer automatically learns what settings you’ve chosen to monitor and creates a dashboard to display how compliant you are for each setting at the current point in time, your trend over the past 30 days, and the list of entities that are currently non-compliant. This allows organizations to have a single dashboard to monitor what’s important to them and to drive compliance with those standards. All of this data can also be exported for integration with other tooling.
Our Jenkins plugin is one of the most popular parts of Twistlock and we’re making it even better in Twistlock 2.0. We now support Jenkins Pipeline which is a powerful way to create build automation as code. Many customers are moving their build jobs to Pipeline to increase efficiency and reusability and the Twistlock Plugin now supports those sophisticated build jobs. Of course, you can also still use the plugin with ‘classic’ Jenkins jobs as well.
Some of our customers, especially those in government and financial services, use multi-factor authentication technologies built on x.509 certificates. For these customers using PKI, Twistlock has added support for authentication to the Console and to the API. This means that whether you’re using smart cards bound to accounts in Active Directory or just want to use ‘soft’ certificates from your own CA, you can now use those certs to authenticate to Twistlock and thus provide strong authentication everywhere your users logon.
In 1.7, we introduced the ability to deploy Defenders via Kubernetes Daemon Sets, which has been a very popular feature with customers. In Twistlock 2.0, we’ve expanded this such that you can also run Console in whatever orchestration cluster you use (such as Kubernetes, Amazon ECS, or Swarm) through our support for persistent volume storage. This means that all Twistlock components can run within the same cluster as the workloads they protect and can be deployed using the deployment artifacts native to the platform you use. For example, if you’re running Swarm, you can run Console as a service and then deploy Defenders to every node in the swarm in a global service.
Nearly all apps use secrets like SSL certificates, SSH keys, and database credentials in their normal operations. However, like in any other use case, when using secrets with containerized apps, it’s important that those secrets not be left in the clear, such as by embedding them into images. Docker and Kubernetes both have great native platform capabilities for storing and distributing secrets safely as part of their normal app deployments. However, it’s important to be able to monitor images and containers for embedded secrets stored in the clear and to actively block non-compliant deployments.
In Twistlock 2.0, we’ve added exactly that capability as part of 2 new compliance checks. These compliance checks look for the presence of x.509 keys, SSH keys, AWS tokens, and other credentials stored in the clear within image file systems or provided to containers via unencrypted environment variables (recall that Twistlock also enables automatic encryption of environment vars). Critically, like any other compliance check, we also allow you to create rules to granularly prevent deployments that are non-compliant. For example, you could create a rule like ‘prevent the deployment of any image with an embedded clear text secret into my PCI environment’. Because we know the state of all your images and are protecting all your hosts, we can ensure that only those deployments that meet your requirements are allowed.
Our file system runtime sensor has always looked for abnormalities in file system writes and for malware affecting containers. In Twistlock 2.0, we’ve expanded these capabilities to provide an even more robust file integrity assurance capability.
First, we now automatically detect certificates within images and monitor any changes to them. This is an important defense against trust poisoning scenarios in which malware manipulates the trust anchors a container uses to validate external entities.
Second, we’ve added user defined file integrity monitoring in which customers can specify individual paths that Twistlock will checksum and monitor for changes during the runtime of the container. For example, you probably don’t want your application’s configuration files to be changing, so you could add /my-app/configand Twistlock will automatically detect (and alert / block) any changes to those files.
Finally, we’ve increased the overall intelligence of our runtime heuristics by integrating process data with it. For example, we now model not just what file paths are written to and read from, but what binaries write what file types. For example, if you have process foo normally writing log files to /var/foo-logs, but suddenly it starts writing binaries to that path, we detect that anomalous behavior.
One of the biggest changes we made in 2.0 is one that’s not directly visible to many customers. From the very earliest versions of Twistlock, Console had always been written in Node.js. With our initial feature set and the scenarios our customers had back in 2015, Node handled our needs well. However, as Twistlock has become increasingly broader and deeper in feature set and the scope of customer scenarios has also broadened, we began to run into some scale limitations with Node. For example, we have some customers with >20,000 images that we monitor and while Node isn’t doing scanning directly, dealing with large datasets at that scale becomes unwieldy and inefficient.
In Twistlock 2.0, we ported the entire backend from Node to Go to push performance and provide us with a more maintainable backend we can more easily add capabilities to. For smaller customers, you’re probably unlikely to notice any change with this move because the Node scale limitations only become evident in large environments with hundreds of hosts and thousands of images. For those customers, the benefits are quickly obvious in the responsiveness of the UI and API. Some statistics for comparison:
Of course, our API routes and UI are not changed by this move, so you get the scale and performance advantages simply by upgrading, no additional change is required to any automation you’ve already built.
The functionality above encompasses the majority of Twistlock 2.0 feature updates. There’s a lot there, and this doesn’t even cover the myriad smaller improvements and updates we’ve made.
Next up: Twistlock 2.1
We’re already working on our next release, Twistlock 2.1, with an eye on shipping within the next nine weeks. In 2.1, we’ll optimize some of the features in 2.0–Specifically, we’ll include functionality that expands upon autonomous policies that protect container applications, and improve the level of actionable insight available to Twistlock customers.
- Application Security
- Container Security
- Cloud Platform
- Container Platform
- Enterprise Security
- Press Releases
- Twistlock General
- Container Registry Scanning
- Runtime Security
- Security Innovations
- Linux Vulnerability
- Zero-Day Vulnerability
- Docker Security
- Open Source
- Customer Success
- Twistlock Partnership
- Vulnerability Management
- Twistlock Product
- Container Adoption
- Container Visibility
- Linux Security
- Google Cloud Platform
- Machine Learning
- Cloud Native
- shift left
- Twistlock Release Notes
- Security Alerts