Periodically re-attest workloads

[evan2645]

Workload attestation currently occurs when a workload first connects to the workload api. This is fine for most use cases, but causes a problem for selectors that may describe runtime state that can change over the lifetime of a workload.

Workload attestation is relatively expensive, and we must block on it when the workload first calls us, but it is not necessary to block on further re-attestations which can be done in the background.

[rturner3]

It would probably be a good idea to evaluate the current selectors supported by the builtin WorkloadAttestor plugins to see which are immutable for the lifetime of a process. One edge case scenario I could think of is for the unix:user, unix:group, and unix:supplementary_group selectors.

Example:

1. Entry spiffe://domain/foo is registered in SPIRE Server with selector unix:user:bob
2. Workload is launched on a host as the bob user, and it receives the identity spiffe://domain/foo identity from SPIRE Agent
3. The bob user is renamed to robert on the host

In this case, the robert user will retain the same uid as bob, but it will fail to re-attest to SPIRE.

I'm not sure how realistic this scenario is in practice, but I will say it is generally more convenient to register workloads by unix:user rather than unix:uid since the user's uid is not always known and may not be stable across all hosts where the workload runs.

[github-actions[bot]]

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