Dynamic/templated Unix attestator registry entries

[calderonth]

Hello,

Is there a way to template registration entries outside of K8s?
I am especially interested at the Unix workload attestator?
If we imagine a large-ish footprint, I wouldn't want to have to write 1:1 mappings for username->spiffe entries.
I can take advantage of Unix groups in selector but I'd want to preserve the original username in the generated SPIFFE claim.

For instance, the ability to build something like that would be super useful I think:

SPIFFE ID        : spiffe://spiffe.hudson-trading.com/admin/{unix:username}
Parent ID        : spiffe://spiffe.hudson-trading.com/parent-policy
Selector         : unix:supplementary_group:admin

I am not (yet) familiar enough with the codebase to check if it's trivial or not to implement but it feels like this should be doable/add value to this workload attestator.

[sorindumitru]

We've discussed this a bit during the contributor sync yesterdqy. The threat model for SPIRE has the spire-agent as untrusted. We limit the SPIFFE IDs that it can request through the registration entries that it is authorized for (are either parented to it or to a node alias of it).

The example given here seems a bit to broad in terms of what the agent will be able to attest. There wouldn't be any checks that there is actually an user running on the same node as the agent. If we do end up making something like this available, we want to make sure that there is still some level of control over who can request what SPIFFE ID.

@calderonth In your deployment would you be able to validate from the server side (e.g. through a plugin interface that doesn' exit at the moment) that a given node (identified for example through its SPIFFE ID or the node selectors [e.g. x509pop:san:cluster:X]) has that user available locally and it should be able to request a SVID with that SPIFFE ID for it? That may be one way to constrain what SPIFFE ID the node can request. Or would having the node information in the SPIFFE ID be an option? For example spiffe://spiffe.hudson-trading.com/cluster/{x509pop:san:cluster}/admin/{unix:username}?

[calderonth]

Interesting.

It was my understanding that the role of the unix workload attestator is indeed to provide some guarantees about the underlying workload that is requesting credentials from a given node. So {unix.username} is rendered out by the spire-agent/workload-attestor which should provide some guarantees that it has matched against a specific local Unix uid/gid/username?
In our case, machines are failry homogenous with users/groups centrally managed so uid/gid/mappings are well controlled on all hosts.
I did give a very basic example to illustrate but I would of course be interested in the ability of templating even more.

For instance:
spiffe://spiffe.hudson-trading.com/{unix:path}/{unix.username} or other enrichments.

I like the idea that the spiffe ID gets templated with plugin/node-level information such as you mentioned.
Alternatively, when looking at JWT SVID, you could add enrichments in the claims as to which node this was requested from (and ideally make it configurable as to what agent-level information we surface in claims)?

[calderonth]

My initial example was too simplistic, this is what I had in mind to constrain issuance only to certain nodes.
I extended the x509pop with custom node enrichments (netbox tags) and then would like to do something like that:

Found 2 entries
# Entry
Entry ID         : 31fbc209-f380-4b37-b5a5-f29bd6332409
SPIFFE ID        : spiffe://spiffe.hudson-trading.com/workload/admin/{unix:username}
Parent ID        : spiffe://spiffe.hudson-trading.com/workload
Revision         : 0
X509-SVID TTL    : default
JWT-SVID TTL     : default
Selector         : unix:supplementary_group:admin

# Node level entry
Entry ID         : a4bc47de-b8da-4ebb-a793-cc2e552b3a19
SPIFFE ID        : spiffe://spiffe.hudson-trading.com/workload
Parent ID        : spiffe://spiffe.hudson-trading.com/spire/server
Revision         : 0
X509-SVID TTL    : default
JWT-SVID TTL     : default
Selector         : x509pop:netbox_tag:workload