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:
- It must provide the necessary mechanisms for separation of concerns, both from an operational as well as a runtime perspective.
- 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.
- It must assume Zero rust. No network should be trusted, even when it “belongs” to you.
- It must provide the flexibility, programmability, and extensibility of a platform that enables customizations to different requirements, balancing simple opinionated APIs with usability.
- It must scale up (and down) to accommodate the needs of different operational environments.
- It must perform under the assumption that a big part of applications is third-party services consumed over APIs.
- 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.
- Service Identity: Instead of identifying applications, workloads, and services by IP addresses or DNS names, we have to provide a cryptographic service identity to every component. This identity is portable with the application and is independent, yet interoperable, with the underlying infrastructure. Public key cryptography is at the center of any such solution.
- Service Context: Following a philosophical approach going back to the teachings of Carl Jung and persona theory, a service should adopt a different security behavior depending on the context that is running in. A service running in the AWS East production environment might have different requirements than a service running in the QA environment in a laptop. It can be the same container, the same code, but the environment (i.e., the context) will demand an entirely different behavior. Understanding and coupling context to security is a requirement to manage security portability.
- Zero Trust and End-to-End Security: The requirements of decoupling from the infrastructure imply two other principles. The first is “Zero Trust,” since the infrastructure belongs to someone else and the notion of the perimeter is obsolete. The second is “End-to-End” because all mid-actors are other sources of vulnerabilities and threat patterns. These principles translate into a simple, yet powerful requirement: end-to-end authentication, authorization, encryption everywhere.
- Flexible Security Execution Environment: Security protection can be done at several layers. We need to avoid the Java lessons of tieing security execution to a language run-time, and we need to avoid the infrastructure assumptions that limit portability. The “Goldilocks Zone” fortunately can be found through capabilities of the Linux kernel and with several technology extensions like namespaces, seccomp, and SGX it will become even stronger over time. The execution environment can be evolved to address additional security needs at different levels of the stack.
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:
- Contextual identity, where a contextual service identity is automatically created for every application no matter what its location or underlying execution environment is.
- A flexible policy layer enables a programmatic policy definition infrastructure that provides a uniform view of the application security posture irrespective of the underlying environment.
- Security enforcement layer that introduces end-to-end authentication, authorization, and encryption everywhere, without requiring any modifications to applications or code.
- Federation capabilities that allow you to distribute applications across regions and clouds without any convergence issues of shared state supporting unpreceded levels of scale.
- Monitoring and analytics capabilities that enable deep visibility into the security posture of each application.