Aporeto Brings Application Security Framework to Kubernetes
Aporeto has announced it is bringing its identity-based approach to securing applications to Kubernetes.
Gregg Holzrichter, chief marketing officer of Aporeto, says the company’s namesake platform makes it possible to enforce network authentication and authorization policies across multiple instances of Kubernetes clusters. That Layer 3 through 7 approach makes it possible to white-list application services deployed on those clusters, he says.
The Aporeto platform is based on what is known as an “enforcer” that gets installed either on a Kubernetes node or virtual machine. Those enforcers communicate with a software-as-a-service (SaaS) application that provides the control plane through which policies are enforced on each Kubernetes cluster. Aporeto assigns a cryptographically signed and attested service identity to every Kubernetes POD. Security policies remain persistent no matter where the POD resides.
Aporeto can import and apply Kubernetes network policy definitions automatically via a YAML interface and supports backward compatibility, which eliminates the need for stacks of unnecessary YAML files. Aporeto also provides access to an application programming interface (API) that makes it easier to enforce cybersecurity policies within a set of DevSecOps processes, Holzrichter says.
Collectively, the approach reduces operational complexity because it eliminates the need to rely on IP address to enforce a zero-trust cybersecurity framework, he notes, adding it also becomes much easier to track changes as new services are added to the environment.
Holzrichter says Aporeto is already being employed to create a zero-trust environment for monolithic applications, so organizations now can apply it to the same framework to securing cloud-native applications on any instances of Kubernetes running on-premises or in a public cloud. Unlike monolithic applications, microservices-based applications are much more likely to move across hybrid cloud computing environments, he notes.
At the same time, Holzrichter says it’s clear cybersecurity teams don’t want to have to acquire, deploy and manage distinct cybersecurity frameworks for every type of application environment an organization embraces.
It’s not clear yet just how many layers of cybersecurity will be required to secure a Kubernetes application environment. The Aporeto approach, however, is extensible in that it can be applied to Kubernetes and services such as Istio service meshes that are deployed on top of Kubernetes.
DevSecOps teams will need to determine to what degree an applications-centric approach to microservices security needs to be augmented with other technologies and services to ensure peace of mind. Right now, cybersecurity concerns remain the biggest inhibitor in adopting cloud-native applications based on containers. The issue that most cybersecurity professionals have with the Kubernetes platforms employed to run those applications is not so much the security of the platform itself, but rather the overhead supporting a platform that today only runs a small percentage of the applications being deployed in the enterprise. Of course, there will come a day when Kubernetes platforms run a much higher percentage of enterprise workloads. However, until that day comes, the onus for making cybersecurity policies as easy as possible to enforce on Kubernetes will continue to fall on developers.
