Make node alias and vanity name entries easier to reason about

[kfox1111]

I would have thought this could work:

spire-server entry create -node -spiffeID spiffe://example/nodename/foo -selector spiffe://example/spire/agent/tpm/xxxxx

But currently another spiffeID is not able to be used in this case, only labels from the agent. Might be a nice thing to be able to do. I managed to work around it by the plugin's own selector for now:

tpm:pub_hash:xxxxx

[evan2645]

Hi @kfox1111 ... I think there is definitely room for improvement here.

Tactically, I think you should be able to get what you want by replacing the -node flag with -parentID and specifying your agent TPM ID there (in addition to your SPIFFE ID selector). Why this works is a quirky side effect of how SPIRE does entry authorization

In the long run, it would be great to make this more approachable. There are clearly use cases for mapping nodes/agents to an alias either via selector or via 1:1 alias. In fact, join token does this kind of 1:1 alias already when creating one with -spiffeID flag.

A new flag like -alias would be nice, though confusing as to when to use -node vs -alias. Perhaps something that deprecates the -node flag and allows for this kind of alias ID creation in both cases...? Just thinking out loud, maybe -nodeAlias where you always specify a SPIFFE ID, and you specify either a selector(s) or a parent ID (mutually exclusive)

# Give a specific agent alias nodename/foo
$ spire-server entry create -nodeAlias -parentID spiffe://example/spire/agent/tpm/xxxxx -spiffeID spiffe://example/nodename/foo

# Give a group of agents an alias to nodename/foo
$ spire-server entry create -nodeAlias -selector aws_iid:tag:nodename:foo -spiffeID spiffe://example/nodename/foo

[evan2645]

Something like the above feels like a step in the right direction with regards to clarifying the behavior of "node entries", and also enabling straight ID aliasing (which is already supported, but not intuitive). We should also document the shapes of the entries that these produce somewhere such that API consumers can leverage them as well. Perhaps that is coupled with proto documentation, and/or new RPCs or params

[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.