Aporeto Embraces Istio to Advance Kubernetes Security
Aporeto, a provider of a platform for establishing zero-trust between microservices by assigning each one a unique identifier, is now moving to integrate that platform with the open source Istio service mesh originally jointly developed by Google, IBM and Lyft.
The Istio service mesh provides a framework for managing microservices running on a Kubernetes cluster. The Aporeto Enterprise security platform adds a layer of security by making it possible to assign a workload identifier to enforce segmentation between microservices, says Aporeto CEO Jason Schmitt.
The goal is to make sure that no microservice inadvertently winds up communicating with any other microservice without permission, says Schmitt.
Istio as a service mesh essentially provides the concept of a load balancer to a Kubernetes cluster. IT organizations still will need traditional load balancers, also known as application delivery controllers (ADCs), to balance workloads across multiple clusters. But within an individual Kubernetes cluster the load balancing function is handled by a service mesh. By plugging the Aporeto Enterprise platform into Istio, it becomes easier for cybersecurity teams to apply and enforce cybersecurity policies to microservices based on containers, says Schmitt, adding those policies are effectively attached to the microservice and remain so should the microservice be redeployed somewhere else.
The Aporeto Enterprise security platform is designed to secure microservices running on-premises or in the cloud regardless of whether Kubernetes is present. But as Kubernetes becomes a de facto standard for deploying and managing containers, adding integration with an Istio service mesh specifically designed for Kubernetes helps advance the state of DevSecOps, says Schmitt. For example, Aporeto Enterprise continuously analyzes container images, applying behavioral analysis using container metadata to identify threats to the container runtime environment, says Schmitt.
The core Aporeto Enterprise platform can be invoked as either a software-as-a-service (SaaS) application or deployed on-premises.
Container security within the context of a larger DevSecOps movement remains a work in progress. In theory at least, developers are assuming more responsibility for implementing cybersecurity policies that are created by cybersecurity teams. The one immediate hurdle is that the tools employed to implement those policies need to be accessible via an application programming interface (API). Developers are not going to want to learn a graphical user interface (GUI). Schmitt says Aporeto Enterprise is designed to provide IT operations and cybersecurity teams with a GUI they use to define policies, which can then be programmatically implemented by developers. The GUI is required because most member of an IT operations or cybersecurity team have limited to no programming skills.
There’s no doubt at this point that microservices and containers will soon force the DevSecOps issue within most IT organizations. The rate at which containers are being ripped and replaced within applications are simply too frequent for cybersecurity professionals to track. The core challenge organizations face now is finding a way to make sure microservices and containers are secure without slowing down the rate at which modern applications are being developed. Achieving that goal requires nothing less than fundamentally rethinking how cybersecurity polices are developed and implemented across the enterprise.
