Workload Identity: Part 1
What is it? And how does it intersect with WebPKI?
The definition and concept of identity changes based on the context and nomenclature of the systems and domains being discussed. Identity is something we’ve been obsessed with since before we learned how to use tools, and of course has gone through many shifts since then.
Identity is a two way street. There is an entity holding an identity, and another entity verifying the first entity’s Identity. This sounds complex, but in reality we do this all the time without really thinking about it. If you’ve lived with someone long enough, you might even identify them through ceilings just based on how they walk! Because of this we also know identity isn’t always as clear cut as something like a Passport.
As the internet allowed us to reach beyond our small circles, it’s also brought in a whole set of technologies that allow us to identify and prove our own identity across this new medium for communication as well. This new medium has also created a whole new set of entities that need to identify themselves, and prove the identity of the entities they talk to: Workloads.
Before we jump into identity and how it relates to workloads, let’s consider a couple of examples of how we use identity on the web.
First, the obvious one is logging in to your account on various websites. Let’s take an average social media website as an example. When you’re logging into that website, you’re trying to prove your identity to the website operator. Then, the website operators uses various technologies (Cookies, IP pinning, etc) to give you a document that allows you to keep proving your identity to that website operator in the background, usually bound to a certain period of time.
Before you even logged into that website, your browser has attempted to verify the identity of the website you’re visiting through TLS and ultimately the X.509 certificate the website presented to your browser.
And before your browser was even able to do that, the operator of that website proved its control over the domain name it operates under, to get that identity document (X.509 certificate).
We also use heuristics to identity to establish trust and accountability all the time as well. For example, we might check a Restaurants reviews on Google Maps to see if we trust going there for our night out or not.
Most communication over the internet is happening “autonomously” between machines. This means that “Workloads” are talking to other “Workloads” on the internet. Workloads talking to workloads actually came before users talking to workloads. Unfortunately though this area has not received as much attention as user identity.
For a long time, and even today, a lot of organizations don’t consider workloads as entities that need identity. There are many reasons for this, a few of which I’ll mention here:
“Trust” in the underlying communications. For example, trusting the underlying network connections, because it’s physically located within a trusted building.
Using secrets (for example, passwords) as a form of identity.
All of these add up to a simple reality: Chronic underfunding of platform security and as consequence, workload identity.
Let’s break down the various forms of identity we’ve traditionally relied on for workloads:
Nothing
There are many organizations out there where if you enter their prod network, you’re “trusted”.
IP Address
For example, our MySQL database is on 10.10.10.12, and our backend is on 10.10.10.13. We setup a rule on MySQL where we say the backend user is allowed to connect directly from 10.10.10.13.
Long lived secrets
Imagine passwords, long lived JWTs, session keys, etc.
As our infrastructure complexity, and understanding of systems has grown and evolved, these systems we’ve used in the past are no longer adequte. Secret sprawl is a serious problem. There have been attempts at inventorying them and providing a better access mechanism for them (e.g. Hashicorp Vault), however an inventory of crap doesn’t really change that you still have crap.
There should be better ways for this, and there have been some shifts in this space over the last couple of years. We’ve heard the concept of ZeroTrust (ZT) come around, and this was an interesting development until so many companies abused that term that it now means nothing. The concept of ZT effectively amounts to “Don’t trust the underlying infrastructure.”
At time time of writing this, the most successful standard for workload identity is ACME. ACME allows a workload to talk to some root of trust and effectively say “My name is {name}. Please verify that and give me a cryptographically signed document backed by {public key}.”
ACME has scaled very strongly. The vast majority of websites used ACME to prove their identity to the various Certificate Authorities that issue WebPKI certificates. However, ACME for workload identity in internal systems hasn’t seen that strong of a growth just yet.
Let’s recap what we’ve learned so far. There are effectively three forms of workload identity:
No direct identity. E.g. trusting the underlying infrastructure.
Long lived secrets.
Cryptographically signed documents trusted with some form of trust.
The first two forms of workload identity are not good. They either put enormous amount of trust in the underlying network, or rely on what effectively is symmetric keys to convey their identity. We’ve effectively started fully moving away from these models for humans and we should do the same on workloads.
Cryptographically signed documents provides us with many interesting capabilities:
Auditability in the form of non-repudiation: If all actions an entity takes is accompanied by this identity document, then that workload can not deny having performed that action.
Integrity: These cryptographic identity documents can be used to establish a trusted communication layer between workloads. This communication layer can use primitives such as TLS and mTLS to provide integrity.
Confidentiality: Similar to integrity, the primitives involved can provide confidentiality with the use of encryption.
Shorter Lifetime: Once we’ve automated the generation of these documents, they do not need to live long at all! We can configure these to live for very short periods of time, or even have them live just as long as some request is happening, and go away right after.
Key non-exportability: Unlike secrets, cryptographically signed documents can be designed such that the private key backing the document isn’t directly extractable. This means that even if some workload behaves maliciously, it won’t be able to exfiltrate that key.
Transparency: Using technologies similar to Certificate Transparency, we can provide a consistent trail of identity documents issued for workloads.
Authorization: Optionally, we can provide authorization capabilities on these documents too. Authorization is a completely different beast than Authentication, and we’ll cover the differences there, and various forms of authorization in a future series.
In the next post, we’ll explore more about the emerging standards in workload identity such as the use of ACME with private CAs, SPIFFE, and why I think these standards are still missing the holistic view of meta identity, and how it relates to workloads, users, and the hybrid mix of these two.