Aporeto Logo
Aporeto Logo

Over the last years, we have witnessed tremendous innovation in microservices, containers, and Kubernetes as some of the components that remove friction points in the application delivery process. The reason we started Aporeto was to identify and eliminate the friction points in the security layer, that is a necessary component of this transition.

But before we talk more about cloud-native security that bridges new application architectures with existing workloads, it is good to visit the evolution:

Docker: The Workload Portability Format

The first part of the journey was the Docker innovation of packaging just the necessary components of applications in a portable format that can be executed in any environment: From an engineer’s laptop to a private or public infrastructure. But, let’s not fool ourselves. Sun had the same vision when it created Java: Write once, run anywhere. However, containers and Docker realized the polyglot needs of current development environments and the complexity of using VMs as the packaging format. To solve the issue, Docker created a much simpler and better abstraction. Kudos!!

Kubernetes: The Deployment Portability Layer

In the era of distributed applications, microservices, and horizontally scalable architectures, deploying a single workload does not solve many problems. Unlike the old Java days, the question is not about running a single workload. Cloud providers had their distinct APIs and ecosystems for helping with scale-out and distributed deployments, but these APIs were centered in the granularity of a VM. Kubernetes dominated the space by providing a common API abstraction for deploying and managing the lifecycle of distributed applications. Essentially, it became the Swiss Army knife of application deployment.  Cloud providers have rushed to offer Kubernetes as a managed service. Google and Azure led the effort and, although it is not wise to make predictions, there is enough evidence that AWS will offer Kubernetes as a managed service very soon.

With these two technologies, it seems that we are finally reaching the vision of “write once, run anywhere” that James Gosling and the Java team envisioned 25 years ago. Or, maybe not yet.

The Security Portability Layer

Running anywhere is not enough for any production workload unless we have forgotten Equifax already. We have achieved the ability to seamlessly move applications from an engineer’s development environment to a massive deployment. We have satisfied the needs of developers and operations teams, but security teams have to address their requirements with technologies and tools that belong to the cloud stone age.

The question we came to ask in Aporeto is how we also make sure that distributed deployments are as secure as ever. Our goal is “write once, run securely anywhere.”  What we set out to do is to create the automated “security portability layer” that enables applications to run with the same security posture all the way from a laptop to a massive production and provide the right tools for security teams to monitor and control this security posture without relying on complex and outdated technologies. And unlike the Java days, security is not just the runtime of an individual container or process, but rather the security of the entire distributed application with all of its interactions. By achieving this goal, not only do we get secure applications, but we also remove the well-known friction: “but it runs fine in my dev environment; Infosec messed it up again.”

The Requirements for Security Portability

Interestingly enough, security portability has pretty much the same high-level requirements as portable workloads:

  1. It must provide the necessary mechanisms for separation of concerns, both from an operational as well as a runtime perspective.
  2. It must be decoupled from the infrastructure and the physical runtime. It can depend on other portability abstractions like Docker and Kubernetes, but it must be able to span cloud providers and implementations.
  3. It must assume Zero rust. No network should be trusted, even when it “belongs” to you.
  4. It must provide the flexibility, programmability, and extensibility of a platform that enables customizations to different requirements, balancing simple opinionated APIs with usability.
  5. It must scale up (and down) to accommodate the needs of different operational environments.
  6. It must perform under the assumption that a big part of applications is third-party services consumed over APIs.
  7. It must work equally well for container only environments as well as a mix of containerized and existing workloads since the world is not homogeneous.

The Key Ingredients of Security Portability Architecture

Solving this problem and requirements requires a different way of thinking. We have been trained for the last 25 years to think about security as an infrastructure, network, or appliance problem. These techniques served us well in static environments, but are failing us in the cloud era. We, therefore, created a thesis and architecture that addresses these problems.

 

 

Achieving the above poses some significant technical challenges. All the way from orchestrating and monitoring security to managing a large-scale identity and PKI infrastructure that is entirely automated. And this is what the Aporeto platform achieves.

The Aporeto Platform

Today, we are happy to announce the commercial availability of the Aporeto platform. What we have created is a zero-trust security layer that follows workloads as they transition between a laptop, a private, and a public infrastructure, providing a consistent security posture, and closing the significant gap of security in cloud environments:  The critical aspects of the platform are:

 

 

 

 

Recent Post Notes and Impressions from this year’s Red Hat Summit Enterprises Are Becoming Cloud-Native, But It Is A Journey – Thoughts from KubeCon Aporeto Collaborates with Red Hat to Deliver Certified Security Capabilities for Red Hat’s OpenShift Container Platform

Subscribe to Our Blog

x