Many identity and access teams have been starting to pick up support requests for an entire gambit of non–person entity related use cases. This often starts with having to handle service accounts – which may end up sitting in the privileged access management camp. Service accounts that are often shared, have permissions, that when misused can cause significant business impact, and often aren’t monitored effectively either.
Next up comes APIs – often leveraging OAuth2 and the dreaded client Id and secret (aka username and password) design pattern. Many API and microservice deployments have now attempted to take on board the “service mesh” approach and you may then start to see the TLS and mutual TLS approach to service authentication based on a single possession factor. However, that too often gets pushed towards the IAM teams and some standard identity capabilities are required – unique identifiers, credential minting, issuance, rotation and reset, permissions management and enforcement and policy management.
As an industry, we sort of jumble this group in the “non-person entity” bucket. The IAM infrastructure isn’t dealing with a person, so it much all be the same. I commented on this back in November with a pretty coarse grained attempted at “Machine Identity 101” described here. Even since then things move on – or perhaps I just become more aware of the nuance and have unlearned some mistakes!
I had a great briefing by the co-founder of SPIRL recently, Evan Gilman. If the name is familiar he co-authored Zero Trust Networks for O’Reilly back in 2017 – well worth a read even if things have moved on a little since then. SPIRL is a startup looking to build out specific support for workload identity. This is based on a standard called SPIFFE – Secure Production Identity Framework for Everyone. The focus here is on software in heterogeneous and dynamic environments.
What does that mean? Well typically systems that are very different to one another and dynamic in the sense they may well be quite short lived, under constant flux and change and maybe deployed in a range of environments. Evan brought up an interesting point about the nuance between workload identity and machine identity.
So in this respect how does a workload differ from a machine? Well machines will typically be host centric and operating system related. That could be anything from bare metal servers (remember those?) right through to more specific devices working in the IoT, industrial IoT, aviation, transport or medical spaces. The net-net, is that the identifier is perhaps linked to something baked into the physical material of the device. Maybe the device has a TPM (trusted platform module) that is shipped with key material that is used in turn to create further derived keys used for authentication or session material. It is also worth adding here that the instantiation of the machine is likely to be one. Of course machines could be virtualised, but the same scale, issuance and governance steps would be applicable.
From a workload point of view, this is most definitely falling into the software world – where scale, instantiation and behaviours will be somewhat different. This workload concept may cover a particular service (aka web front end) right down to a particular process. This workload world will also introduce some interesting concepts too – how to avoid secret zero, how to define an identifier, prove ownership of that identifier and in turn rotate and reset issued credentials. SPIFFE is here to help with a lot of that.
The emerging demand for workload related management is seeing a few interesting challenges. Do organisations look to build out a management infrastructure themselves or start to build atop of things like SPIFFE (and SPIRE which is essentially a server/agent approach for deploying SPIFFE).
Clearly workload identity will also require a range of management capabilities too – from reporting, visibility, discovery, cryptographic agility options right through to more tightly built integrations, recipes and deployment accelerators.
Like we saw with OAuth2 and OIDC a decade ago, the standard itself is just the first step in the long road of adoption – where the repeatable and observable needs for production are not always met.