Hi, does it make sense to enhance Consul agent to support SPIFFE Workload API (https://github.com/spiffe/spiffe/blob/master/standards/SPIFFE_Workload_API.md) and to support attestation processes similar to what’s implemented in SPIRE (https://spiffe.io/spire/concepts/)?
- I understand that Consul already support the SPIFFE SVID format today. However, Consul does not support SPIFFE Workload API, which mandates the absence of direct client authentication to assign identity to the calling workload.
- I think supporting SPIFFE Workload API would simplify Consul configuration management by not requiring to specify service definitions in the config files.
- For example, when an application such as Envoy launches, instead of calling Consul Connect for the private key of “app1”, the application, aka the “workload”, would ask “who am I?” to a local Consul agent running in client mode via UDS. The local Consul agent would be responsible to perform an out-of-band authenticity check to determine which identity this “workload” should be assign to and return a matched SVID. On linux, such check could be based on the agent interrogates the node’s kernel to identify the process ID of the caller. The caller and the Consul agent must run on the same node. The process ID would then be used to lookup other info such as k8s kubelet or an AWS Instance identity document. These additional info would be used to match a pre-registered service definition from the catalog.
- In this model, the identity of a workload is lazily provisioned at runtime only based on where the workload is running on, and what identity has that environment be registered to.
- Personally, I find this model to be compelling because a workload cannot spoof to take on a service identity if it’s running in the wrong environment.
I’m interested to work on this and eventually submit a pull request. Before I dive in, is this enhancement desirable for Consul? Should I raise this as an issue on GitHub?
Thanks in advance,