Announcing Twistlock 18.11
We just signed off on Twistlock 18.11, the 15th time we’ve shipped a major release of Twistlock and almost exactly 3 years from our first release at DockerCon Europe 2015. You probably noticed that we’ve changed our versioning scheme with this release. Since we sell Twistlock as a subscription, we thought it made sense to adopt a date based versioning scheme like Windows and Docker itself. Going forward, we’ll still have the same release cadence and support lifecycle, but releases will be versioned as YY.MM of the date of release. The third digit in the version is the build number and continues to be sequential.
The usual fun facts from GitHub: we’ve worked on 11000 issues, pushed 5800 commits, built Twistlock more than 900 times, and shipped over 300 customer requested features to a couple hundred customers over the past 3 years!
In addition to the major new features below, this release includes dozens of other smaller improvements including:
- Many new alert providers: Prometheus, PagerDuty, generic webhooks, AWS Security Hub, IBM Security Advisor, logging to stdout
- Cloud Native Application Firewall (CNAF) for Fargate
- A central, product wide, credential manager to make it easy to securely store and reuse accounts and keys for external services
- Network runtime defense for serverless, embed Defender through the UI
- Support for scanning images directly with twistcli on macOS and Windows
- Enhanced management and summarization of audit events
— the Twistlock R&D and product teams
Herzliya and Baton Rouge
Cloud Platform Compliance
As providers continue to add new cloud native services, it becomes increasingly difficult for customers to ensure the apps running on them are protected. Consider the fact that all major cloud providers today have:
- Container image registries (e.g. ECR, ACR, GCR)
- Container as a service platforms (e.g. Fargate, Azure Container Instances, Google’s serverless containers)
- Managed Kubernetes platforms (e.g. EKS, AKS, GKE)
- Serverless platforms (e.g. Lambda, Azure Functions, Google Cloud Functions)
Also consider that many enterprise customers are choosing an intentionally multi-provider strategy for commercial reasons and that most enterprises have many separate accounts per provider (such as different accounts per business unit or geography). This situation can easily result in hundreds of combinations of providers, accounts, and regions where cloud native services may be deployed. It’s impractical to manually monitor which of these services are being used, where they’re being used, and whether they’re being protected.
Twistlock’s new Cloud Platform Compliance feature helps organizations centrally discover all the cloud native services in use across AWS, Azure, and Google, across all your accounts, and in every region. Cloud Plaform Compliance continuously monitors these accounts to detect when rogue services are added and continuously reports on which services are unprotected. Cloud Platform Compliance can send alerts when a new service is discovered so you always know what’s running and can avoid risks introduced by rogue deployments, abandoned environments, and environments not being protected by Twistlock.
Cloud Platform Compliance covers container image registries, container-as-a-service platforms, managed orchestration platforms (including ECS), and serverless platforms across AWS, Azure, and Google Cloud.
Twistlock for Pivotal Cloud Foundry
Twistlock has supported Pivotal Container Service (PKS) on PCF since it launched. In 18.11, we’re expanding this support to Pivotal Application Service (PAS) as well. PAS is the Cloud Foundry BOSH based platform that until recently was referred to simply as PCF. While PCF PAS uses a container based approach to running apps, it uses a technology that pre-dates Docker and runc.
In 18.11, Twistlock can be installed directly from the Pivotal Network marketplace and is deployed as a native “tile” into your existing PCF cluster. Twistlock scans droplets in any blobstore and detects vulnerabilities using our industry leading dataset delivered by the Intelligence Stream. Twistlock can also be easily integrated into any CI/CD flow that ultimately runs apps in Cloud Foundry to find vulnerabilities and enforce policies at build time.
Istio is one of the most interesting new technologies in our space because it helps simplify many formerly difficult aspects of running microservices. Notably, Istio provides load balancing, fine grained traffic routing, TLS everywhere, and service centric RBAC. What Istio doesn’t provide natively, though, is a simple way to visualize and understand interconnectivity between services. In 18.11, Twistlock integrates with Istio to discover this service mesh and uses this data to enrich the radar with details about protocols and service roles used with Istio.
18.11 also includes an industry first set of compliance and secure configuration checks for Istio. Designed by our Twistlock Labs research group, this family of checks adds to Twistlock’s library of more than 300 individual compliance checks already covering Docker, Kubernetes, and Linux. The Istio family of checks enables customers to enforce a secure Istio configuration and cover key risks like misconfigured TLS settings and universally scoped service roles.
We originally shipped Radar over two years ago in Twistlock 1.6 and have improved on it in every release since. In 18.11, we’re elevating Radar to be the primary interface users engage with for monitoring and understanding their environments. In addition to the Istio integration described earlier, Radar in 18.11 has many UI and UX improvements to enable teams to truly understand their environments and navigate easily throughout all our data. For example, not only can you visualize all connectivity between microservices, but you can also instantly drill into our per-layer vulnerability analysis, monitor for compliance, and investigate incidents, all without leaving the Radar canvas. Of course, we’re not removing or deprioritizing the detailed, tabular monitoring views we also have, but with 18.11 you’re able to access everything directly in Radar.
Kubernetes service account monitoring
Kubernetes has a rich RBAC model based around the notion of service and cluster roles. This model is fundamental to the secure operation of the entire cluster because these roles are used to control access to resources and services within namespaces and across the cluster. While these service accounts can be manually inspected with kubectl, it’s almost impossible to visualize and understand their scope at scale by doing so.
In 18.11, Twistlock includes a first of its kind discovery and monitoring tool for these accounts. Integrated into Radar, every service account associated with every resource in a cluster can be easily viewed. For each account, Twistlock shows detailed metadata describing the resources it has access to and the level of access it has to each of them. This visualization makes it easy for security staff to understand role configuration, assess the level of access provided to each service account, and mitigate risks associated with overly broad permissions.
- Twistlock Platform
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