Design: Workload Identity

Author: Stuart Douglas

Description (what)

Workload identity is how a module can identify its caller.

Goals

• A FTL module should be able to securely determine which service it is being called by
• This should apply to both inter-module FTL calls and ingress, however ingress is out of scope of this initial design
• SPIFFE should be used as the identity representation

Non-Goals (optional)

• Ingress (both gRPC and HTTP) are out of scope of the initial design.

Design (how)

FTL will delegate as much of this as possible to Istio, and let istio validate workload identity through mTLS. When mTLS is in use Istio sends a header to the application x-forwarded-client-cert that contains the workload identity. An example of this header is as follows:

By=spiffe://cluster.local/ns/demo/sa/time;Hash=c375deb88df05d1717d9ff36fd8ba475213cff842b95908a5fc35ffb3760ed45;Subject=\"\";URI=spiffe://cluster.local/ns/default/sa/ftl-console"

FTL language runtimes will extract this identity from the header, and provide ways for the end user to access it.

Go

The runtime will provide a ftl.WorkloadIdentity interface that can be injected into a verb. It will provide methods to retrive the Spiffe URI, as well as possibly other convienience methods.

JVM

The runtime will provide a xyz.block.ftl.WorkloadIdentity interface that can be injected into a verb. It will provide methods to retrive the Spiffe URI, as well as possibly other convienience methods.

TODO: should these schema record that these verbs depend on the workload identity?

When runnout outside Kubernets (e.g. ftl dev/serve) then FTL will spoof this header and add the header on outgoing requests.