In late May, Google, IBM and Lyft launched Istio, an open-source platform for managing and securing microservices. Because Istio lives within the extended DevOps and container ecosystem, I’m sharing this overview as insight into what it is generally, and how the current model may work with Twistlock.
What is Istio?
Based on Envoy by Lyft, Istio is an intelligent and robust web proxy for traffic within your Kubernetes cluster as well as incoming traffic to your cluster (i.e. it covers east-west, north-south), plus it has a nice management layer.
It’s Robust: Istio runs in real world scenarios at 2 million requests per second
It’s Intelligent: Istio supports stuff like SDS on the proxy level, and has a management system that supports stuff like A/B testing, fault injection etc
It features an ambitious roadmap: While Istio is currently a proxy and a management layer on top of Kubernetes, it is slated to work with other container orchestration systems in the future.
It’s seamless to the application: It doesn’t require involvement of the application developer, nor does it require an IT person to configure IPs. Everything is defined on the service level, so it’s extremely low maintenance.
Examples of Key Functionality:
- Istio collects traffic logs, and then parses and presents them for you: For example, you can monitor traffic for specific services. This isn’t surprising, since Isitio installs Prometheus under the hood for log collection and Grafana for visualization.
- Istio enables you to specify access control rules for web traffic between Kubernetes services via a component called Mixer, that each proxy delegates its policy decisions to, thereby enabling users to configure based on attributes of the traffic. Further, Istio features a language that enables you to specify which Kubernetes services can talk to other services and automatically discovers the pods that implement these services, wherever they may run.
- Isito enables you to seamlessly enforce encryption and authentication between node, so you get IPSec like / MTLS like / HTTPS like capabilities between nodes. Istio generates a new CA cert for each Kubernetes cluster, then uses that to issue a new KPI identity for each Kubernetes service, which is later used for service-to-service seamless encryption.
- Istio’s A/B testing functionality provides a kind of “Google for everyone else” level of capabilities, so you can start testing new services by routing some of the traffic to them, and make sure they behave–just like Google does.
- Fault injections: The access rule you specify using the mixer supports cool, modern stuff like fault injection. For example, the mixer policy supports an element called “aborts” and “delays”, which allow you to intentionally see how your application behaves in corner cases.
Kubernetes uses a traffic proxy, so why do I need Istio too?
Kubernetes has a L3/4 element that creates a virtual IP for multiple pods’ nodes that creates a virtual IP for multiple pods’ nodes running the same service, and features an optional ingress module that enables incoming traffic. Istio makes these features less “required” functionality, but while Istio works well with HTTP traffic, it isn’t that great with TCP and UDP yet. Ultimately, Kubernetes and Istio work best side-by-side, at least for now.
Don’t Weave and Calico provide overlapping capabilities with Istio?
Calico and Weave are network plugins for Kubernetes, and Istio is a web proxy, so there shouldn’t be direct overlaps. One could say that access control and seamless encryption are two areas where there’s a bit of overlap, but there are multiple areas where there is zero overlap. Furthermore, given that Weave and Calico are both betting on Kubernetes, most likely there will soon be some modular solution that enables both elements to live on the same stack.
Couldn’t this be another open source white elephant that will fade away
This is definitely not another white elephant. There are impressive and relevant brands behind the project, as well as container Joe Beda, who a huge influencer in the container space, plus was the key driving force behind the “Google for everyone else” concept, given his years and years of containers experience with Google.
Can’t I do all of the things you mentioned above today using scripting and the our devops team?
You can theoretically, using tons of scripts and your own choice of web proxy, but it would be a very hard to get it to discover services automatically, route traffic without causing delays, and seamlessly manage AuthN/AuthZ.
If access control is defined in the proxy level, why should I worry about application security?
There are two main reasons to worry about application security:
- Network enforcements allow you to block unwanted network access, but that can’t be the only source of anomaly sensor you use. There are other important sensors you must use, which exist on the endpoint itself, that sense an application’s behavior (e.g. system calls sequencing, processes, and others). In other words, an attacker can move inside your cluster according to the access control rules you gave them, hopping from host to host. To protect against that you’d want to analyze any anomalous behavior using other sensors.
- Known threats can come through your front door– it is kind of an “old school” approach, but you still want to filter known attacks out. For example, if someone sends you a SQL injection attack, you want to block it before it gets to your machine, regardless if the tunnel it came through was secure or not.
How do I enforce application security in the scenario?
If you use Twistlock – there is nothing that you need to change to support this scenario. Moreover, the application definitions we can extract are clearer in this scenario, and enable us to force stronger “whitelisting” of application behavior. Specifically the access control of Istio, complements the whitelist controls enforced by Twistlock, on all levels: system-calls, process layer, network layer, and storage layer. This means that the network layer is easier to understand and is more predictable, so our machine learning elements have fewer anomalies to account for.
Istio is a solid enabler for any organization to have a state of the art, containerized production environment. It’s early days but if you like using bleeding edge products, you should strongly consider it.
Sign up for our newsletter or follow us on Twitter to get more cloud native ecosystem updates.
Follow us on Twitter
Follow us on Twitter for real time updates on the cloud native ecosystem, Twistlock product, and cloud native security threats.
Cloud Platform Discovery: Identifying All Your Cloud Native ServicesRead the Blog
Using Twistlock to Secure Workloads on Pivotal Cloud FoundryRead the Blog
Twistlock, Azure Container Instances, and AKS virtual nodesRead the Blog
Twistlock 18.11 Release NotesRead the Blog
5 Questions to Ask When Choosing a Cloud Native Security Platform for DevOpsRead the Blog