Last week, a new company called Aporeto advanced an architecture whose purpose, it said, would be to enable microsegmentation in containerized applications on Kubernetes. Its aim, it wrote in a note to The New Stack, is to “make it possible to segment distributed applications regardless of… the network topology.
“R.I.P. SDN, microsegmentation, nano-segmentation, etc.,” the note concluded.
Aporeto’s system is called Trireme, named for the rower-powered ancient Greek warships that spearheaded the first great navies between the 7th and 5th centuries B.C. Its architects claim that once deployed, Trireme will eliminate the need for containerized applications or microservices to communicate with one another using network addresses. In their place would be 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.
“The problem that’s existed, and the fallacy in thinking, has been that if A and B can ping each other, it’s assumed that they’re authorized to talk to each other,” explained Aporeto founder Amir Sharif, in an interview with The New Stack. “And we don’t believe that’s the right approach. We believe A and B should ping each other if and only if they’re able to talk to each other. Our approach is one of a whitelist, basically. A and B, by default, are blocked from talking to each other unless there’s a policy that exists for them to communicate with each other.”
Sharif described his Aporeto system as a policy-driven service communication facilitator, built on the Kubernetes platform, using K8s’ recently introduced Network Policy API. He believes that if the orchestration platform is capable of identifying containers and running services by their pod labels, IT operators would no longer have to engineer SDN networks and network overlays to enable communication between them. The orchestrator (in this case, Kubernetes) would manage all the mapping.
Trireme would supplement this mapping component with a system for what Sharif described as “micro-identity:” unique, and probably ephemeral, identifiers for services.
“The whole idea is that Service A gets a set of attributes — labels, if you would — that define it,” he explained. “By virtue of policy, you say that given the micro-identity of Service A, is it allowed to contact Service B? And vice versa; can B be tracked to A, by policy, and connect to it?”
Can We Trust “Security Cookies?”
Attributes play individual roles in helping to determine the identity of a service in the Trireme system. When a service sends out a request, Trireme attaches cryptographic data to the SYN packet in the TCP/IP packet. That becomes possible, he said, thanks to Google, which in 2011 published a protocol that attaches to TCP/IP, called TCP Fast Open.
A 2011 research paper published by Google [PDF], along with researchers from the University of California at San Diego and Berkeley University, describes the generation of a so-called “security cookie” that’s attached to TCP/IP handshake data. “We believe that this cookie mechanism provides an acceptable defense against potential denial of service attacks,” the researchers wrote.
By attaching micro-identity to the SYN and ACK packets of TCP/IP protocol, using the method the Google team created, Sharif said, it can be made to pass through existing firewalls and network routers. Optionally, the attachment to the SYN packet can be encrypted. The same attributes that determine identity when the token is created, can then be used when the SYN packet is received to validate that identity.
“I receive the micro-identity that’s cryptographically signed,” explained Sharif, “and I say, ‘Is Service A entitled to talk to Service B?’ And then I pass the SYN packet back to the receiver, and the receiver repeats the process with an ACK packet. In that way, both sides do a tight handshake.”
Trireme enables attributes to be added to the identity data arbitrarily, he went on, such as the container image’s checksum, or the IP address of its source server. Developers may then write processes that leverage that data to produce policies.
The way container networking currently works in most environments, the network that containers perceive is produced by an overlay on top of Layer 3, which contains the address scheme for the virtual servers and the container hosts. But Google engineers are already on record as saying they see Kubernetes users moving to a flat L3 routing scheme, and that they like what they see.
Aporeto’s Sharif argues that Trireme makes it feasible for container networking to happen entirely on Level 3, without overlay networks. That would reduce the cost of implementing hyperscale containerization, perhaps to the extent that it may finally tip the scales for many data centers in containers’ favor.
But does this place too great a burden on an unproven system of cookie exchange between IP packets, to guarantee the type of policy-driven security that containerization currently lacks? More to the point, is Trireme placing too great a burden on labels?
Without mentioning Aporeto or Trireme, we discussed this issue with Brandon Philips, the CTO of CoreOS, a major contributor to Kubernetes.
Philips told us that role-based access control (RBAC) already exists within Kubernetes, as part of its API. So defining complex policy is already part of the Kubernetes framework, assuming that policy has any definition. That’s coupled with the ability to export and capture audit logs of events recorded in a cluster, including the modification of labels.
“If you trust in the role-based access control of Kubernetes, and you trust in the ability of the audit system inside Kubernetes,” said Philips, “labels absolutely can be used as a mechanism for tagging and enforcing security policy.”
However, he warned, such policies should be designed to “fail closed.” For example, a blanket security policy may be put in place where nothing can talk to anything by default. Labels may then be assigned specific, limited rights.
“Say that you have a cluster-level policy, then a namespace-level policy, and then a label policy. You can set [RBAC] rules on a namespace to ensure that only people who have operational trust in that particular namespace can modify objects inside of that namespace, and then labels that they apply to that are implicitly trusted because they’ve been given a role that gives them access to deploy software and apply labels in that namespace.”
So Aporeto doesn’t have to reinvent the wheel with respect to policy and enforcing it. But it does offer a way to attach that policy to containers (or, theoretically, to whatever components Kubernetes may manage in the future) that’s at least stickier than a Post-it note.
While vendors such as VMware plan ways to “embrace” Kubernetes by building a nice cubby-hole for it inside its hypervisor-driven or network-virtualized environments, Aporeto may be the first of several small companies to demonstrate how Kubernetes could function quite effectively as the center of the entire lifecycle management system.
Aporeto and CoreOS are sponsors of The New Stack.
Title image of penguins congregating at Cape Adare, Antarctica, by George Murray Levick, traveling with the Scott Expedition in 1911-12, in the public domain.