Hello, Service A. I'm Service B.

I often ask my graduate students at NYU and Stevens to define proof. They usually respond that a proof is some inference from axioms and proven theorems. And yes, if your assertion can be traced to accepted facts, then you’re on the right track. But the truth (ahem) is that a proof is just a damn good argument. This is a total bummer, because a bad, incoherent argument might serve as perfectly acceptable proof to an ignorant target.

The concept of proof as a good argument is interesting when one robot offers proof of an assertion to another robot. The cadence you’d expect is this: “Robot A: I’m A. Robot B: Prove it. Robot A: Here is proof. Robot B: Hello A.” Unfortunately, it doesn’t always go so simply and smoothly (e.g., watch the chat-bot volley in this video). But modern computing demands that we implement proof of assertions between automated systems.

This technical challenge came up last week during a discussion with Sunil James, CEO of San Francisco-based Scytale. James took me through a whirlwind of information about service-based identity authentication across cloud, containers, and enterprise. The motivation for James’ work is that challenges in mutual service identity slow down the velocity of cloud adoption. Let me share what I learned about the Scytale approach:

“To achieve full adoption of cloud,” he said, “we must somehow glue together the identity management systems for all the various services involved. In a sense, authentication is becoming, and maybe it has already become, one of the major bottlenecks to service growth as well as to full virtualization of the enterprise. Solving the technical and infrastructure security problem of service authentication is what Scytale is all about.”

We should start by recognizing that whenever identity management and authentication are desired for a traditional LAN-based enterprise, it is relatively straightforward to establish a source of truth for credentials. IT and security teams typically integrate their Active Directory with a commercial identity and access management (IAM) system. And while this is not a simple task, it is a tractable one, with years of demonstrable success.

For mutual service authentication, however, the strength and resilience of distributed XaaS infrastructure are balanced by the loss of centralized identity management. Luckily, some smart minds have been on the problem: Enter SPIFFE and Spire. And no, this is not a pair of Yorkshire Terriers. Rather, these frameworks have emerged from the expert security teams at Google and elsewhere. They also serve as underlying bases for the Scytale offering.

SPIFFE stands for Secure Production Identity Framework for Everyone, and it is a set of open-source standards for securely identifying software systems in dynamic and heterogeneous environments (And, yes – I am copying this word-for-word from their website). You could say that SPIFFE produces a sort-of identity passport using the familiar X.509 standard to present credentials to remote service workloads.

SPIRE stands for SPIFFE Runtime Environment, which basically implements platform and workload attestation. It does this through an API that controls attestation policies and coordination of certification issuance and rotation (and these words are also snarfed directly from the aforementioned website). SPIFFE and SPIRE are used by many different projects with cool names like Knox and Ghostunnel that you can go research if you are interested.

So, the Scytale offering is built on this notion of workload (aka service) authentication to other services (aka workloads) by presenting passport credentials that are validated through a certificate-based attestation process. And if that sentence made perfect sense to you, then you just-might-be a cloud identity expert. For the rest of you normal folk, the Scytale platform should help make things a bit easier through automation and pre-integration.

To understand the Scytale approach, it helps to view the service authentication challenge as consisting of three obligations. The first involves the creation of a service identity using MFA that will work across desired platforms. The second involves understanding and mapping how each service must be represented to other services. And the third involves delivering certificates and short-lived tokens to connect to a given workload.

“Our platform delivers frictionless, consistent, and compliant authentication across all platforms,” James said. “We support one configuration for all business units, we enable mapping of all desired services, we integrate with existing service managers, and we use existing user management systems with RBAC, SAML, and SCIM. This, collectively, is our business value proposition.”

Adoption of Scytale for mutual service identification is likely to be well-received because it is general framework-based, and because it addresses a speed bump to cloud. Granted, this solution is not for everyone – and I suspect many CISOs and security teams with less experience in authentication standards like OAUTH and FIDO will have some trouble making sense of how this all works.

But for network, cloud, and service architects seeking automation to assist in the complexity of stitching together identity management for their respective workloads, this sure looks like just what the doctor ordered. If you’re in this camp, give Sunil James and his team at Scytale a call and then share back with all of us everything you learn. (And please don’t forget to offer valid proof of identity when you share . . .)