Integrating Calico and Istio to Secure Zero-Trust Networks on Kubernetes
Networks without trust
The concept of zero-trust networking (ZTN) was introduced in 2010. At the core, the ZTN model means not allowing access to anyone unless they are authenticated and their request to a specific network resource has been authorized. ZTN builds on the following principles:
- Networks should always be assumed to be hostile.
- External and internal threats exist on the network at all times.
- Network locality is not sufficient for gaining trust.
- Every device, user, and workflow should be authenticated and authorized.
- Network policies must be dynamic and calculated from as many sources of data as possible.
While ZTN can offer better security—as all traffic needs to be verified—it can also be a challenge to adapt. At a recent Kubernetes meetup held in San Francisco, Andrew Randall of Tigera illustrated how the combination of Istio and Calico can work together to ensure security for zero-trust networking on Kubernetes.
How can Calico and Istio help?
Calico is an open-source project designed to remove the complexities surrounding traditional software-defined networks and securing them through simple policy language in YAML. Calico is compatible with major cloud platforms, such as Kubernetes, OpenStack, Amazon Web Services, and Google Compute Engine.
“If you’re trying to establish trust, just the fact that someone else is on the same network as you is not sufficient to say you trust them.” —Andrew Randall, Tigera
These policies allow users to restrict access to specific services and separate development from production workloads. Policies are also dynamically updated through a distributed algorithm that determines what rules are required on each node in a cluster.
“Calico’s network policy API allows you to define at a granular level—based on fundamental Kubernetes concepts like labels—how you’re going to allow connections between workloads in your cluster.” —Andrew Randall, Tigera
On the other hand, Istio, another open-source project, resides on the concept of a service mesh by installing an Envoy sidecar proxy as close as possible to an application. This enables management of both the proxy and the application. Recently, we’ve written about using Istio and service mesh to achieve uniformity across microservices deployed to Kubernetes.
In the context of security, Istio provides authentication and encryption through mutual TLS—where both client and server use certificates to verify identity—and cryptographic certificates issued to each
serviceAccount. More importantly, Istio ensures that security is implemented in a consistent way across an application.
“Rather than implementing mutual TLS in the application, with Istio you drop in a sidecar into every pod and that takes care of encrypting the connections using mutual TLS.” —Andrew Randall, Tigera
Integrating Calico and Istio
On August 18, 2018, Calico v3.2 was released. This combined Calico’s application layer policy with Istio to enable authentication and authorization of network traffic using varying parameters.
“We take the network policy and apply that to the Istio proxy layer, as well. There’s an authorization API within Envoy, and it allows us to read the policies right there in the proxy as it’s managing the traffic going through. The key value here for the user is there isn’t a separate place they have to go to find Istio connectivity rules from the network policy connectivity rules.” —Andrew Randall, Tigera
By integrating both Calico and Istio, the network policy language can be extended to include
serviceAccounts. This way, validation is done through both network identity and cryptographic certificate.
“I’m validating on both the network identity and the identity based on this certificate. Another endpoint can exfiltrate that certificate and try to connect, but if it doesn’t have the same network identity, it’s not going to get through. Equally, another endpoint can spoof the IP address of a valid client, but if it doesn’t have a certificate, it’s not going through.”
—Andrew Randall, Tigera
Kubernetes labels can also be used in the network policy language.
The network policy can also be configured to include a combination of attributes. For very strict policy controls, even connection methods can be defined.
“You’ve got super fine-grained rules, which are all about locking down connectivity to just what should be allowed.” —Andrew Randall, Tigera
Tigera’s enterprise solution
At the end of the presentation, Andrew showed a snippet of the Tigera Secure Enterprise Edition—a platform that uses Calico and Istio under the hood to enable a ZTN model for enterprises. The solution removes the need to manually code network polices by using GUIs and other visual aids for traffic and security management.
The Tigera Secure Enterprise Edition also provides visibility and traceability by logging all network traffic between microservices and applications. Furthermore, it can be configured to automatically quarantine workloads that are acting irregularly, as well as can send alerts for inspection.
Organizations with strict compliance and regulatory requirements can benefit from Tigera’s audit logs. These contain a detailed history of security controls and also include changes to security policies.
As can be seen, though Istio and Calico secure each specific layers of a network, the combination of both technologies can be handy for Kubernetes deployments.
Want details? Watch the video!
Table of contents
These are the slides by Andrew.
At the meetup, Simone Morellato of VMware delivered a demo of the company’s container solutions for Kubernetes.
- Using Istio to Unify Microservices with a Service Mesh on Kubernetes
- Improving Security for Kubernetes Deployments at Scale
- Cloud Foundry Advisory Board Meeting, Aug 2018: Istio and Eirini