This article is about Istio, a new service mesh management platform that works with Kubernetes to make it easier to deploy, operate, and scale microservices across any cloud. Twistlock is integrating with Istio to secure these service meshes by enriching its machine learning about connectivity with Istio data, using Istio to quarantine compromised services, and providing compliance policies to enforce secure configuration.
As cloud native becomes the default way to build and run modern web scale apps, organizations need increasingly sophisticated tools to abstract the underlying complexity away from normal operations. Kubernetes is the clear winner of the orchestration arms race and abstracted the complexity of managing large fleets of compute nodes. However, as Kubernetes enables ever larger deployments, it can benefit from a companion technology that leverages it’s platform level primitives to make managing large portfolios of services simpler. For example, Kubernetes makes it easy for you to deploy an app that scales across a 1000 node cluster and deals with deployment and node failures. However, it can be complex to route traffic for that service, to monitor the overall health of the service (not just of individual nodes and pods), and to ensure fair resource allocation between this service and others within the cluster.
Istio is a project designed to complement Kubernetes (and potentially other microservices platforms) and provide such capabilities. Istio’s goals are to provide traffic management, service identity, management policy enforcement, and telemetry to microservices. Istio is built around the open source Envoy proxy hosted by the Cloud Native Computing Foundation. Istio builds on existing Kubernetes capabilities to make deployment familiar and integrated, while providing a variety of value add services beyond Kubernetes’ more infrastructure specific focus.
Over the past few months, more and more of our customers have been asking about Twistlock’s plans for Istio and today I’m happy to share those details. Istio is a complex platform with diverse configuration options and security settings, and it’s easy to get lost within all the details. While it’s easy to get started running Istio, having visibility into traffic flows, enforcing security best practices, and (maybe most importantly) leveraging Istio’s capabilities to improve the security of your apps are the areas we’re focused on enhancing.
To explore the new security features Twistlock provides, we’ll use the common Bookinfo example app. As described in the guide, this app is composed of multiple interconnected microservices:
- productpage. The productpage microservice calls the details and reviews microservices to populate the page.
- details. The details microservice contains book information.
- reviews. The reviews microservice contains book reviews. It also calls the ratings microservice.
- ratings. The ratings microservice contains book ranking information that accompanies a book review.
The topology of the app is depicted below.
Visualizing and Controlling Istio on Radar
One of the first challenges we recognized with customers using Istio was in being able to visualize the topology of services. While we’ve long had the Radar view in Twistlock that provides a real time ‘Visio’ of your entire containerized environment, with Istio we can further augment this data with more application specific knowledge and depth.
One of the main security benefits of Istio is tight control over network policies. That is, strict control over the communication protocols and connections between entities. To provide this, it’s recommended to enable service level access control in Istio. When you’re using this feature with Twistlock, you gain full visibility and control over network topology directly in Radar’s visual canvas.
For example, in the Bookinfo example, the productpage service receives a product-viewer role that is bound to the productpage-viewer and details-reviews-viewer service roles. The first role indicates that all users can access the product page, while the second role is explicitly set for the product page and enables only it to access the details and reviews services. All of this configuration is automatically learned by Twistlock, dynamically updated, and annotated to the Radar canvas for each service:
Further, when clicking on the service roles, you can drill down to see the details for each:
Using Twistlock, we can edit and manage all the security settings that are associated with a given entity, and see those changes reflected in Istio’s managed service mesh topology.
Leveraging Istio for Runtime Quarantine
We also integrate our runtime defense sensors with Istio, adding deep security intelligence over the overlying topology by analyzing the allowed connection and infrastructure metadata across entities. Using this data, we report and quarantine entities based on the network metadata and observed behavioral anomalies.
For example, in the Bookinfo app, what happens if an attacker successfully achieves remote code execution on the productpage service and from there tries to access the ratings service? Technically, if all mesh rules were configured correctly, Istio network policies could prevent the connections, but you still need detection and alerting of the compromise, which comes through CNNF’s (our layer 3 Cloud Native Network Firewall) integration with Istio:
Of course, these network violations are also reported and shown in Radar:
This flow enables Twistlock to apply our ML driven behavioral modeling to automatically detect anomalies, but to then offload response to Istio for isolating the compromised service. For example, Twistlock can quarantine a public facing web service where an anomaly is detected by instructing Istio to disconnect that service from the backend payments database. Because this integration occurs at the service mesh layer, Istio can instantly and elegantly enforce it across the environment, without requiring changes to IP routing or manual port reconfiguration.
Finally, our Twistlock Labs research team has developed a set of new compliance checks for Istio. These compliance checks are aligned to existing best practices from the Istio project and community, such as ensuring mutual TLS is enabled in the production namespace and that strict role based access control is enabled. These compliance policies fit into Twistlock’s existing compliance capabilities, including the ability to alert and block based on non-compliance and to see status globally in real time in the Compliance Explorer dashboard.
As customers deploy and run more complex cloud native apps, platforms like Istio complement existing capabilities in Docker and Kubernetes to provide every customer with planetary scale tools. At Twistlock we’re proud to lead the way with the industry’s first Istio aware security platform – not just compatible with Istio, but actually leveraging it to scale and integrate security along with your service mesh.
Related Kubernetes Security Posts
- 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.
IAM Roundup: AWS vs. Azure vs. GCPRead the Blog
How to Securely Configure a Linux Host for ContainersRead the Blog
Don’t Forget the Audit Trail! The Role of Reporting in SecurityRead the Blog
Securing Cloud Native Applications on Pivotal Container Service (PKS)Read the Blog
What to Know: Gartner’s Security Considerations and Best Practices for Securing Serverless PaaSRead the Blog