Istio SPIFFE IDs are based on the service accounts. We likely want them based on the workload

Identifying services directly

Often it is valuable to identify services directly. For example, an administrator may decree that any process running on a particular set of nodes should be able to present itself as a particular identity. For example:

spiffe://staging.example.com/payments/mysql or spiffe://staging.example.com/payments/web-fe

The two SPIFFE IDs above refer to two different components - the mysql database service and a web front-end - of a payments service running in a staging environment. The meaning of ‘staging’ as an environment, ‘payments’ as a high level service collection is defined by the implementer.

Identifying service owners

Often higher level orchestrators and platforms may have their own identity concepts built in (such as Kubernetes service accounts, or AWS/GCP service accounts) and it is helpful to be able to directly map SPIFFE identities to those identities. For example:

spiffe://k8s-west.example.com/ns/staging/sa/default

In this example, the administrator of example.com is running a Kubernetes cluster k8s-west.example.com, which has a ‘staging’ namespace, and within this a service account (sa) called ‘default’. These are conventions defined by the SPIFFE administrator, not assertions guaranteed by this specification.

https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE-ID.md#22-path