Using Network Policy in Concert with Istio — Part 3

This is the final installment of our series on Using Network Policy in Concert with Istio. It is also the most speculative because I’ll be discussing where we think open source projects are going to go in the future.

Istio’s long term vision is to be a framework for developing microservice applications such that nearly all the tricky parts of connecting distributed systems at scale are delegated to the Istio service mesh and microservice developers can focus on business logic of their services. It’s a compelling vision, but needs to be broken down to really understand what it means to you.

Istio has a huge head start on this goal by building on the Envoy proxy, which addresses lots of headaches operating distributed systems like load-balancing, retries, circuit breaking, etc. — what Oliver Gould calls Magic Operability Sprinkles.

To those of us in the Cloud Native echo chamber, it seems like everyone is using service meshes, but the wider reality is one of a long tail of applications, services and even network-based appliances that need to interoperate. Until the Istio service mesh is completely omnipresent in our applications it’s a hard sell to rely entirely on Istio policy for security.

Increased Breadth of Istio Environments

Presently, Istio is (by design choice) fairly limited in terms of the applications you can run in the service mesh; specifically, it supports HTTP services running in Kubernetes clusters. Both of these choices are forward looking. There is a huge wave of support for HTTP as a service layer, one that is easily a decade old. Kubernetes on the other hand, has been out for barely two years, and while it has emerged as the most popular container orchestration system, the reality is that most enterprises are just starting to dip their toes into the container space. I’d wager that if you exclude Google applications and picked an application at random more often than not it’ll be VMs or bare metal running that app, rather than containers.

The developer community around Istio realizes the need to expand the scope of applications that can take advantage of it, and so you should expect to see increased support. The Istio 0.2 release is specifically “focused on expanding the coverage of Istio to more places.”

In the near term they expect to be able to support VMs participating in the service mesh, as well as support for generic TCP connections. Longer term I expect to see them cast the net even wider, possibly via 3rd party offerings and plug ins.

More Comprehensive Istio Policy Options

While in part 2 of this post we mostly discouraged users from relying on Istio for their security goals, moving forward the Istio team is planning to substantially increase their offering. Istio Auth will be the backbone of authentication in the service mesh. These cryptographically verified identities will be passed to a pluggable authorization system, along with a rich set of layer 7 attributes. This will give policy implementers ever finer control, to control access to specific services, calling particular RPC methods, on particular API objects/resources. While much of the short term work is focused on HTTP+Kubernetes semantics and attributes, I expect the same widening of the net to occur in the authorization space, and for Layer 3 and Layer 4 selectors to be available as well. The long term dream is that application writers can delegate authorization entirely to Istio and configure it centrally in the mesh.

Future of Network Policy

Given that we expect to see expansion of Istio’s capabilities into new environments, and for Layer 3 & Layer 4 selectors become available for Istio policy, how will the role of Network Policy evolve? My expectation is that there will be a mix of deployments: some using only Network Policy, some only Istio and some that will use both for defense in depth. Depending on the existing environments and applications where they are adopting Istio, they will have to choose a policy paradigm that fits or at least co-exists well within their infrastructure. For applications that fit entirely in the mesh, Istio policy may soon meet their needs. In mixed environments with services both participating and not participating in the mesh, Network Policy will continue to make sense, perhaps combined with Istio for advanced policy capabilities, like allowing some entities read-only access to an HTTP API (GET but not POST or PUT, for example).

The other chink in Istio’s armor is the architecture of enforcing policy in the same network namespace as the application code. We require egress policy for many security use cases, as detailed in Part 1 & 2 of this series. Compromised or malicious endpoints can simply bypass the proxy. Network Policy enforced by the host is much, much harder to get around. Calico supports egress policy today, enforced in the underlying host’s kernel, and this capability will probably come to the Kubernetes Network Policy API soon as well.

Conclusions

The obvious “right” answer from the security perspective is defense in depth, but far fewer companies will choose this model if they are forced to configure Istio and Network Policy as disjoint subsystems in their infrastructure. They will choose one and spend their security dollars/people on other areas. The big challenge for the community is how to design and build configuration and monitoring interfaces that give application developers and operators a unified, multi-layer model of application policy.