Feature Request: Simplified support for single-workload nodes

[JackOfMostTrades]

Hey folks, we're looking at migrating our sevice-mesh PKI ecosystem to SPIRE and I wanted to describe an issue that's proving to be a bit blocking for us.

In our ecosystem we don’t have distinct notions of nodes and workloads. Rather, all of our “nodes” are single-workload systems. The containers/VMs in our ecosystem attest themselves as nodes do in the SPIRE model, but they use the credentials they get directly for remote service calls (so the credentials these “nodes” get are the equivalent of a “workload” credentials). We therefore don’t have any notion of a registration database since all node/workload identities are derived from node attestation.

Given this, we’re having some difficulty transitioning our ecosystem to SPIRE since it seems like every workload needs a registration entry. While we could create a registration entry for every possible workload, this is not ideal. For one, it does not scale well to the many thousands of applications in our ecosystem. Secondly, our existing orchestration and deployment pipelines do not presently have a hook to “register” new workloads in our ecosystem, and instead we rely solely on out-of-band attestation to determine workload identities.

While I am open to other options (such as support for registration entry templating), for our use-case the most direct solution would be to allow the credentials received from node attestation to be made available directly via the workload endpoint. I would imagine that the node-attestor or node-resolver plugins could emit a flag that indicates the SVID is a workload SVID. When SVIDs flagged this way are returned to an agent, the agent would then expose this credential directly via the workload endpoint rather than using the SVID as a credential to fetch separate workload SVIDs. This would save us to migrate to SPIRE without needing to build and maintain a registration database which is otherwise superfluous in our ecosystem.

[azdagron]

This feature request aligns with some of our thoughts around agentless workloads (e.g. AWS lambda) and its something we've considered adding for some time, just haven't settled on the details yet (e.g., do we introduce a new plugin type to "attest" these workloads or do we re-use node attestors, how do we enforce trust-on-first-use, etc).

Can you elaborate a little on the credential your workloads use? Can it be shared among workloads or is it guaranteed unique per workload? Is it a simple token or something a little stronger like an X.509 certificate? If you don't want to provide these details, that is of course OK.

[JackOfMostTrades]

Sure, so we use X.509 certificates pretty similar to X509-SVIDs. The identities are unique per workload and are rotated frequently as with SPIRE. For workloads running on EC2 our attestation is pretty similar to aws_iid. We also run workloads in a container ecosystem similar to k8s but in that case the control plane injects container identity documents into the container and attestation is pretty similar to aws_iid from there (but obviously with a different root of trust). We actually also do something similar with AWS lambdas, but the attestation is based on the IAM role of the lambda (the attestation basically being a pre-signed URL for STS.getCallerIdentity).

The common thread is that the workload directly attests itself and then that workload identity is shared by anything within the boundary of what was attested (i.e. the EC2 instance, container, or lambda execution).

[github-actions]

This issue is stale because it has been open for 365 days with no activity.

[github-actions]

This issue was closed because it has been inactive for 30 days since being marked as stale.