ATMCOMIO

The Maritime Future of IT?

I’m not sure where the obsession with nautical entities in the cloud/data center startup world came from, but from where I’m standing, it looks like taking an aquatic stance is a reasonably good predictor of success. Let’s see… Docker has the cute little whale. Kubernetes comes from a Greek word that refers to the helmsman of a ship. MariaDB’s logo is a cuddly little sea lion, which has similar contours to MySQL’s dolphin. DigitalOcean, GlassFish, Jetty… Shall I go on?
Recently, a cloud security startup briefed us on a project they’ve been working on which has – you guessed it – a thalassic slant.

Evolving Application Segmentation for the Cloud

Just as the trireme (a kind of Greek warship) is an evolution of the bireme, Aporeto has recently announced an open source project that is an evolution in application segmentation. Trireme is available fortrireme-logo-final-b anyone to leverage as of November 1st, and Aporeto is actively encouraging folks to go download and use the tool.
The goal is to provide simple, secure, and scalable application segmentation. Here’s what I think that could look like based on the capabilities of Trireme.

Simple

IT security is brutally complex, especially in a post-cloud world.  Traditionally, IT organizations have segregated applications with architecture methods such as VLANs, explicit routes, and ACLs. While those strategies still have their place, all of them become quite cumbersome to manage at scale. It also becomes a brain-melting exercise to keep it all straight in a multi-tenant environment where all of that is happening inside of a growing pile of overlay networks.
I recently wrote about how Illumio eliminates all of this complexity in a VM-centric data center by controlling access at the VM level with an in-guest agent. Trireme uses a very similar model, but with a focus on application containers. (Note that enforcement can also act on bigger entities like a Kubernetes pod, or on more granular entities like a specific Linux process.)
In Aporeto’s example implementation, which I’d highly recommend trying out, they use the example of using the Docker monitor implementation to watch for certain container labels. There’s a policy set to only allow communication between containers with the same label. So containers labeled ‘web’ can all talk to each other. But a container labeled ‘app’ is disallowed (by policy) from communicating with anything labeled ‘web.’
A real-world implementation would be substantially more robust; however, it would not necessarily be more complicated. Securing via policy is really that simple. Consider this: which IP address a container has, which VLAN or network it lives on, or which other networks it has access to are now unimportant from a security standpoint. The vision for the architecture is a minimal number of big, flat networks, and all security is done via container/process-level policy. Neat!

Secure

Of course, your eye probably twitched when I suggested that it would be reliably secure to allow services to co-exist on one flat network. Although I do have a few questions about exactly how high this scales from a networking standpoint (broadcast domain, etc.), there is a major component of the Trireme architecture that should put your mind at ease.
[su_box title=”From the Trireme GitHub page:”]PU identities are cryptographically signed with a node specific secret and sent as part of a TCP connection setup negotiation. Trireme supports both mutual and receiver-only authorization. Moreover, it supports two authentication and signing modes: (1) A pre-shared key and (2) a PKI mechanism based on ECDSA. In the case of ECDSA, public keys are either transmitted on the wire or pre-populated through an out-of-band mechanism to improve efficiency.
Trireme also supports two identity encoding mechanisms: (1) A signed JSON Web Token (JWT) and (2) a custom binary mapping mechanism. With these mechanisms, the Trireme run-time on each node will only allow communication after an end-to-end authentication and authorization step is performed between the containers.[/su_box]
What this means is that it’s possible to configure an environment which implements Trireme to disallow communication that is not mutually authenticated and authorized. And it can tie in to your own public key infrastructure for the signing and distribution of keys.

Scalable

The last consideration the Aporeto team has focused on is that of scalability. Microservices architectures are causing the number of instances (containers, processes, or otherwise) under management to skyrocket. The traditional methods of data center segmentation are operationally crippled under the new volume. Imagine that 100 instances various services are created and destroyed each day. (This is low to many organizations.) The overhead of creating a new ACL for each of those instances is overwhelming.
aporeto_introduction_pdf
If the creation for all those ACLs is successfully orchestrated such that no intervention is required, there’s still the issue of the security gear maintaining the massive rule tables and processing the mountain of rules required to keep this strategy in working order. Because Trireme enforces rules based on an “identity” which is unique to the application and not on ephemeral descriptors like IP addresses, the solution can scale to support very large systems.

Learn More

I’ve thoroughly enjoyed learning about Trireme, and I’ll be excited to see how Aporeto’s commercial product (launching some time in the not-too-distant future) will provide the user-friendly, enterprise-ready management layer for all of the cool technology in Trireme. I don’t know anything about it at this point, but based on what I’ve learned about Trireme, I can speculate that it will be neat!
If you’re interested in digging a bit deeper, here are some helpful resources: