So, let’s say you have heard great things about a service mesh and are excited about the Istio open source project. Maybe you’ve even decided to move your application (or part of it) into a service mesh. We have spoken at length about the importance of Network Policy to secure applications, and given that Istio also supports policy, we want to spend some time explaining how Istio policy and Network Policy interact and support each other to deliver your application securely.
We will cover this topic in 3 parts:
- Part 1: What’s different about Istio policy and Network Policy?
- Part 2: How to configure policy today
- Part 3: What might future development of Istio and Network Policy look like?
Let’s start with the basics: why might you want to use both Istio and Network Policy? The short answer is that they are good at different things. Consider the main differences between Istio and Network Policy (as implemented with Project Calico):
Istio policy operates at the “service” or “RPC” layer of your network application. This is Layer 7 (Application) from the perspective of the OSI model, but the de factomodel of cloud native applications is that Layer 7 actually consists of at least two layers: a service layer and a content layer. The service layer is typically HTTP, which encapsulates the actual application content as requests and responses. It is at this service layer of HTTP that the Istio proxy operates. In contrast, Network Policy operates at Layers 3 (Network) and 4 (Transport) in the OSI model.
Operating at the service layer gives the Istio proxy rich set of attributes to base policy decisions on, at least for service protocols it understands, which at present is limited to HTTP/1.1 & HTTP/2 (e.g. HTTP headers). So, you can apply policy based on virtual host, URL, or other HTTP headers.
In contrast, operating at the network layer has the advantage of being universal, since all network applications use IP. At the network layer you can apply policy to DNS, SQL databases, real-time streaming, and a plethora of other services that do not use HTTP. Network Policy isn’t limited to a classic firewall’s tuple of IP addresses, proto, and ports. Both Istio and Network Policy are aware of rich Kubernetes labels to describe pod endpoints.
Lastly, Calico policy can extend beyond the service mesh (including to bare metal or VM endpoints not under the control of Kubernetes), allowing you to control policy across a hybrid network with a single API.
The Istio Proxy is based on Envoy, which is implemented as a user space daemon in the data plane that interacts with the network using standard sockets. This gives it a large amount of flexibility in processing, and allows it to be distributed (and upgraded!) in a container.
Calico’s network policy data plane is based on iptables, which are packet filters implemented in the standard Linux kernel. Being in kernel space means they are extremely fast, and iptables is shipped with every standard Linux kernel. Network policy is limited to Layers 3 and 4, so not as flexible as the Envoy proxy.
Policy enforcement using the Istio Proxy is implemented inside the pod, as a sidecar container in the same network namespace. This allows a simple deployment model. However, since the proxy is in the same network namespace as the service instance, if the service is compromised, or misbehaves (as in a malicious tenant) the proxy can be bypassed.
While this won’t let an attacker access other proxy-enabled pods, so long as they are correctly configured, it opens several attack vectors:
- Attacking unprotected pods
- Attempting to deny service to protected pods by sending lots of traffic
- Exfiltrating data collected in the pod
- Attacking the cluster infrastructure (servers or Kubernetes services)
- Attacking services outside the mesh, like databases, storage arrays, or legacy systems.
Calico’s policy is enforced at the host node, outside the network namespace of the guest pods. This means that compromised or misbehaving pods cannot bypass policy enforcement. Calico supports applying policy to the egress traffic of protected pods, allowing you to defend against the above attacks.
Our take is that Istio Proxy and Network Policy with Calico have different strengths as policy. Istio is HTTP aware and highly flexible, making it ideal for applying policy in support of operational goals, like service routing, retries, circuit-breaking, etc. Network Policy is universal, highly efficient, and isolated from the pods, making it ideal for applying policy in support of security goals. Furthermore, having policy that operates at different layers of the network stack is a really good thing as it gives each layer specific context without commingling of state and allows separation of responsibility.
Next: read how to configure policy with Istio and Kubernetes Network Policy, in Part 2 of this series.