SPIFFY Mutual TLS (mTLS) is a way to secure workload identity and communication in a distributed system using the SPIFFE and SPIRE standards. (see also: https://spiffe.io/) SPIFFE stands for Secure Production Identity Framework for Everyone, and SPIRE stands for SPIFFE Runtime Environment. SPIFFE defines a platform-agnostic identity format and API for workloads, and SPIRE provides a system for issuing and verifying SPIFFE identities.
An East-West service mesh like Istio or Cilium could be a good place to enforce policies based on “workload identities” derived from the claims of the X.509 client certificate. Let’s say the policy is “version2” clients can’t call “version1″ endpoints.” Thanks to Christian Posta for the solo.iowebinar showing how in Cilium we could define a policy like this:
From an enterprise policy management standpoint, do I want network policies in my service mesh? It means I need to learn a one-off policy language. For example, Cilium has its way they express policies (see above). But KrakenD uses the CEL policy language. And there are a hundred other systems that might need to consume enterprise policies. Wouldn’t it be better to follow the lead of Kubernetes access control, and use OPA to manage policies, or some other PDP–pick from an increasingly vast array like Axiomatics , Aserto , Permit.io , SGNL ? Just to name a few…
We want the speed of decentralization, but the consistency and operational leverage of central control. eBPF enables kernel-level optimizations and leaps forward in performance. But metaphorically, it doesn’t mean having a bunch of ACL’s in the router is the right thing, even if we can run those ACL’s faster then ever!
As an OAuth person, I see a lot of overlap between an MTLS workload identity (e.g. a “a kubernetes service account”) and an OAuth “client”. You can connect these two worlds–RFC 8705 defines a mechanism to bind OAuth access tokens to a client’s mutual-TLS certificate, enabling endpoints to verify the access token presented was actually issued to the client presenting it. You could also achieve this with DPoP (RFC 9449), which might be better, because MTLS doesn’t work for mobile clients. The real edge is the super computer in people’s pocket.
