Incorporate SPIFFE Workload API and SPIRE-like attestations to Consul

Hi, does it make sense to enhance Consul agent to support SPIFFE Workload API ( and to support attestation processes similar to what’s implemented in SPIRE (

  • 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,

Hi Simon,
It’s worth nothing that in our Kubernetes implementation, we do something similar to this. An init container logs in to Consul via an auth-method with its ServiceAccountToken. Consul then authorizes this against the Kubernetes API server. This returns an ACL token that allows the init container to register a specific service name (and also receive the certificate for that service).

I work on the Kubernetes side of things so unfortunately can’t answer your main question but thought it worth responding.

Simon also opened an issue on GitHub where @banks has already replied.

Sharing the link so that others can follow the conversation there.

Thanks guys I will continue this conversation at connect: add SPIFFE Workload API and SPIRE-like attestations support