Kubernetes / Security / Service Mesh

Aporeto’s Kubernetes Security Platform Offers Multiregion Cluster Support, Service Mesh Integration

29 Aug 2019 9:07am, by

Zero-trust cloud security company Aporeto has expanded its set of Kubernetes security hosted software to include multicluster and multiregion deployments, and paves the way for multiple service mesh integration.

This service comes with network layers 4-7 support, which “allows users to balance between performance overheads and security requirements.” Aporeto co-founder and Chief Technology Officer Dimitri Stiliadis wrote in an email. The addition of these networks layers provides the needed visibility and granularity.

“In most cases, network security in Kubernetes clusters through network policy is implemented as L3 security. This is obviously limited since not much information is available at this layer. The Aporeto solution extends network security to layers L4-L7 providing real visibility to security operations on what is happening in the cluster,” wrote Stiliadis. “With a single click, an operator can deploy mTLS across all Kubernetes clusters without worrying about detailed network policies. Workloads will use load balancers or service meshes and the Aporeto solution provides a unified identity and security framework across all these implementations. In addition to supporting security enforcement, through our own data plane, we also support security enforcement across service mesh implementations using the Envoy proxy.”

The upgrade also includes support for running multiple services meshes. By using the Envoy proxy, Aporeto now enables the mixing and matching of various service meshes. Aporeto works with all container network interface architectures and service meshes, as well as all Kubernetes formats, including AWS EKS, Google GKE, Microsoft Azure AKS, IBM Cloud Kubernetes, and local installations such as Red Hat OpenShift, kubeadm and Heptio. Stiliadis says this is core to Aporeto’s approach.

“Automation and extensibility is the core of the platform,” wrote Stiliadis. “With our Function-as-a-Service capability embedded in the platform, operators can automate repetitive security tasks, alarms, and alerts through a programmable framework of functions that is invoked based on security or measurement events. Essentially the platform provides an extensibility framework to customize operations in any environment.”

When The New Stack first wrote about Aporeto in 2016, the company was focused on Trireme, a “userland process, container, or [Kubernetes] DaemonSet that is easily deployed onto each host to stand in front of the TCP/IP stack” that would replace the use of IP addresses with “a mechanism of metadata that identifies applications exclusively as members of collective pods, and that bridges the gaps between them not with VxLAN or with Docker plug-ins, but with a loosely coupled system of labeling.”

Now, Aporeto continues to employ application identity-based, rather than IP address-based, security and policy management. It is through this approach that the company now says it can handle more complex Kubernetes environments. Currently, Aporeto does this using either a SPIFFE certificate or fully compatible OAUTH/OIDC credentials, which workloads can use to securely authenticate and authorize themselves with third-party services and applications without the use of secrets.

Stiliadis told The New Stack that the move to multi-cluster Kubernetes deployments made the traditional IP-based approach untenable. Aporeto’s approach, he wrote, not only moves beyond problematic IP-based approaches but also decouples the security control plane entirely from the Kubernetes control plane, providing end-to-end security without the overhead of understanding and managing complex network topology.

“Providing even simple network security in such multi-cluster environments is challenging to say the least. By relying on workload identity and end-to-end authentication and authorization, the Aporeto platform supports multicluster and multiregion deployments of network security,” wrote Stiliadis. “In multicluster Kubernetes, network topologies are very complex. Different clusters can have different IP address ranges, often overlapping. NAT gateways, Load Balancers, etc. between clusters modify IP addresses. This makes it extremely complex to do network security with IP address-based techniques.”

Feature image by Reimund Bertrams from Pixabay.

A newsletter digest of the week’s most important stories & analyses.

View / Add Comments

Please stay on topic and be respectful of others. Review our Terms of Use.