So what is this Apollo Proof Of Concept that I’m building out? In a nutshell, it’s a large scale distributed system that provides decentralized identity and stored secrets management. More precisely, we can describe this POC as A Multi Tenant Service Providing Identity, Authorization, Authentication and Stored Secrets Management.
Let’s call it the Sky Application (because I like Egyptian gods). It’s a wildly ambitious project and as such should be seen as an experiment, rather than a glorious path to some other goal.
The Sky Application
The Sky application is a distributed system in the classic sense. It is not a decentralized system in that all the pieces of the system are managed and owned by a single entity. I know that bothers a lot of folk, but I’ve also seen the complete lack of any enthusiasm in any valuable project for a decentralized system where folks run their own parts of the system. Running things is hard and no one wants to do it.
The distributed Sky application does, however, provide a decentralized identity and secrets storage system in which external entities have control over the identity and secrets management provided by the Sky application to these Tenants. The trust comes not from the provider of the Sky service, rather it derives from the way the Sky service operates.
Sky is an edge oriented system, rather than a centralized system. It is designed to provide services at the edges – interactions – of client tenants, providing a low latency trust and mediation service. Resources and data are located where the clients need them. Data and operations within Sky are distributed and provide cross region replication and consistency so that disparate clients can securely interact.
The building block of the Sky application is a single, replicated process providing identity, access control, key management and replicated storage. I use the cheesy diagram below to represent this cell in future diagrams.
These processes are part of a (potentially) global distributed system and essentially operate identical code. These processes act in concert providing the highly available, byzantine fault tolerant services for Sky.
So let’s unpack the top level requirements a bit.
Multi Tenant
Right off the bat, Sky is designed as multi tenant. It is, in fact, much simpler to start off with a single tenant system, but that’s like playing tennis without the net. Of course it’s simpler to start off without doing the hard thing. Requiring a multi tenant solution right off the bat may be a bit harsh, but it does impose some fundamental design decisions both from an architectural point of view and from a security point of view. And it’s precisely the issues that a simplification of a multi tenant system by a single tenant approximation that I wish to bypass with this architecture, so it’s focussing on the hard things front and center.
Multi Tenancy is also the way Sky scales. It’s extremely challenging to shove everything into a single logical centralized system at scale. And an obvious way to deal with these challenges is to partition – or shard – the system. And multi tenancy is mostly just a fancy way of describing a sharded system. Rather than simply being a harder problem than single tenancy, starting with multi tenancy from the beginning provides an architectural design pattern we can use for scaling the system out. We don’t have to scale any centralized thing to infinity and beyond. Rather, we leverage the natural hierarchical storage decomposition that results from hierarchically managed domains – aka a Tenant.
Identity, Authorization and Authentication
To my thinking, it’s very difficult to disentangle these three fundamental services. Identity is a fundamental requirement for both Authorization and Authentication. Consequently, my belief is that separating out these functions is likely to end only in tears. So the Sky application provides the fundamental identity service and uses this identity in authorization and authentication the sister services as well as providing the basis for secrets management.
Identity Service
The identity service defines how identity is defined and managed. In addition to managing the top level identities, this service also provides these identities the ability to manage their own subsets of identities – e.g., Users, processes, etc.
Authorization Service
The Authorization service provides answers to authorization questions concerning identities, actions and the subject of these actions. The service uses the managed identities and provides an access control queries. The service apes the venerable access control model of Google’s Zanzibar and provides the same consistency mechanism for authorization queries similar to the Zookie does for Zanzibar
Authentication Service
The final service of this triad is the Authentication service. The service provides the means and mechanisms to prove identity and can thus be thought of as a generalized attestation service. Identity attestation encompasses the low level “I’m process XYXZ and here’s my proof” as well as the high level “I’m administrator GOD and here’s my password, tokens, 2FA, etc”.
Secrets Storage
A Secrets Storage service fulfills a fundamental need by providing clients secrets they are authorized to have. Providing secrets is required for just about everything in a distributed system and that becomes challenging as the system scales. The Secrets service requires and is built on the previous identity services and can thus securely provide the secrets to correctly authenticated identities.
Decentralized Identity On A Distributed Architecture
Ultimately the Sky application is an experiment to see how far I can drive the idea of Decentralized Identity on a Distributed Architecture. Decentralized Identity is about a tenant controlling their own identity, their own authorizations. Providing this model on a distributed system is challenging because the tenant isn’t running the system; rather a single entity runs the distributed system that is used to provide the decentralized identity services.
While not an original idea, the purpose of this experiment is to move from the world where identity and thus trust is centralized (on the left in the diagram above) to a decentralized model where Identity is managed by the entities themselves (the right side of the diagram). This transforms cloud based integration from a hub and spoke model to an edge centric, peer oriented, highly distributed integration that mediates and manages trusted interactions across many disparate systems.
Is That All?
My lord, isn’t that enough? 😀 Yea, it’s ambitious and it’s something that will of course be perpetually unfinished because it’s a pretty vast thing. And certainly doing any significant work on this ends up being cool in and of its own right. Which is why Apollo is highly modularized. The pieces that have been developed in support of this madness are all designed to be reusable. It’s literally impossible for me to not design things to be reused and leveraged in different contexts and systems. ¯_(ツ)_/¯
What’s next?
Next post I’ll provide some use case examples of what Sky will provide via its various services.
Leave a Reply