# Design: Workload Identity
**Author**: Stuart Douglas
<!-- Status of the document - draft, in-review, etc. - is conveyed via HackMD labels -->

## 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.