Key Takeaways Istio helped make the "service mesh" concept more concrete and accessible, and with the recent release of Istio 1.0, we can expect a surge in interest. Istio attempts to solve some particularly difficult challenges when running applications in a cloud platform: application networking, reliability, and observability. Another challenge Istio addresses is security. With Istio, communication between services in the mesh is secure and encrypted by default. Istio can also help with "origin" or "end-user" JWT identity token verification. These foundational security features pave the road for building "zero-trust" networks where we assign trust based on identity as well as context and circumstances, not just "the caller happens to be on the same internal network".
Istio helped make the "service mesh" concept more concrete and accessible, and with the recent release of Istio 1.0, we can expect a surge in interest. Jasmine Jaksic did a great job introducing Istio and service mesh in a previous InfoQ article, and so I would like to take the opportunity to introduce a particular area of Istio that will bring lots of value to developers and operators of cloud services and applications: security
Istio Use CasesIstio attempts to solve some particularly difficult challenges when running applications in a cloud platform. Specifically, Istio addresses issues around application networking, reliability, and observability. In the past we've tried to use purpose-built application libraries to solve some of these challenges like circuit breaking, client-side load balancing, metrics collection, and others. Doing this across different languages, frameworks, runtimes, etc creates a prohibitive operational burden that most organizations can't scale.
Additionally, it is hard to get consistency across the implementations found in each language, never mind upgrade them all in lock-step when things need to change or bugs are identified. A lot of challenges around reliability, observability, and policy enforcement are very horizontal concerns and are not business differentiators. Although they are not directly differentiators, neglecting them can cause massive business impact, and so we need to address them. Istio aims to solve these concerns.
The Importance of Network SecurityAnother one of the horizontal, difficult to get right, concerns for application teams is security. In some cases, security is an afterthought, and we try to shoehorn it into our apps at the last possible moment. Why? Because doing security right is hard. For example, something foundational like "encrypting application traffic" should be commonplace and straightforward, right? Configuring TLS/HTTPS for our services should be straight forward, right? We may have even done it before on past projects. However, getting it right in my experience is not as easy as it sounds. Do we have the right certificates? Are they signed by the CA that the clients will accept? Are we enabling the right cipher suites? Did I import that into my truststore/keystore properly? Wouldn't it just be easy to enable the “--insecure” flag on my TLS/HTTPS configuration?
Mis-configuring this type of thing can be extremely dangerous. Istio provides some help here. Istio deploys sidecar proxies ( based on Envoy proxy ) alongside each application instance that handles all of the network traffic for the application. When an application tries to talk to http://foo.com it does so via the sidecar proxy (over the loopback network interface ) and Istio will redirect that traffic to the other service's sidecar proxy which then proxies the traffic to the actual upstream http://foo.com . By having these proxies in the request path, we can do things like encrypt the transport automatically without the application having to know anything. This way we get a consistently applied traffic encryption without relying on each application development team to "get it right".
One of the issues with setting up and sustaining an implementation of TLS and mutual TLS for your services architecture is certificate management. Istio's Citadel component in the control plane handles getting the certificates and keys onto the application instances. Citadel can generate the certificates and keys needed for each workload to identify itself, as well as rotate certificates periodically so that any compromised certificates have a short life. Using these certificates, Istio-enabled clusters have automatic mutual TLS. You can plug in your own CA provider root certificates as needed as well.
With Istio, communication between services in the mesh is secure and encrypted by default. You no longer have to mess around with certificates and CA certificate chains to get TLS working. Operators no longer have to hope and pray each developer properly implements and configures their TLS/HTTPS settings correctly. It's done for you automatically through some Istio configurations.
Using Istio to enable mTLSIstio follows the same path to configuration as Kubernetes does. Actually, on Kubernetes, Istio is configured with Kubernetes Custom Resource Definition (CRD) objects. The two main objects for configuring Istio's security policies are the Policy and DestinationRule object. Policy objects are used to configure the security settings of a service (or group of services). For example, to configure all services running in the customer namespace in Kubernetes, we can use the following Policy object:
apiVersion: “authentication.istio.io/v1alpha1”kind: “Policy”
metadata:
name: “default”
namespace: “customer”
spec:
peers:
When we use this configuration, services running in customer namespace will expect any incoming traffic to use mTLS. But to use mTLS, we also need to tell the clients to use mTLS when they call a service. To do that, we'll use an Istio DestinationRule. A DestinationRule in Istio is always used to configure how clients talk to a service. With a DestinationRule we can specify things like circuit breaking, load balancing and TLS. To enable mTLS, we can use a configuration like this:
apiVersion: “networking.istio.io/v1alpha3”kind: “DestinationRule”
metadata:
name: “default”
namespace: “foo”
spec:
host: “*.customer.svc.cluster.local”
trafficPolicy:
tls:
mode: ISTIO_MUTUAL
This DestinationRule will require clients use mTLS when making calls to services in the customer namespace. We are also configuring the tls mode to be ISTIO_MUTUAL which means we'll expect Istio to manage the certificates and keys as well as mount them into the services (using Kubernetes secrets in Kubernetes) so that the service proxy can use them to establish TLS. If we wanted to have our own control over the client certificates, we could use a mode of MUTUAL and also supply the location on disk where the client can find its certificates and private keys.
Using Istio to validate origin identity (with JWT) When we use mTLS as described above, we can not only encrypt the connection, but more importantly know exactly who is calling whom. Istio uses the Sec