Flag for jwt preference entry
At the entry level, it would be good if you could mark the entry likely to be JWT only. This way, SPIRE can prevent spending effort precreating x509 certs for workloads that wont use them.
@kfox1111 I'd be happy to work on this one
This sounds like a good improvement. We need to figure out how to best represent this in the datastore; we'll discuss this some more and come back with a proposal.
@kfox1111 @tjons If a workload tries to fetch an X509-SVID for an entry that is marked as JWT-only, would you expect the call to fail or have the agent requesting the SVID from the server (since it's not in the cache)? If the agent requests the X509-SVID to the server, would you also expect that the agent keeps it updated in the cache (handling rotation)?
That is a good question....
Depends on if its a preference flag, or a hard 'no' flag.
if it was an enum, it could have more complicated logic like, "nevercert" which could return no and "nocache" which is don't ever prebuild a cert, its rare to ever ask for a cert.
a middle ground might be:
- dont preallocate certs. if one is asked for, give it. if the connection is left open, cache and refresh it. if the connection is closed, its unlikely they will ask again and just drop it from the cache and dont refresh?
I'm ok with just a hard no too. That is probably easier.
Thank you, @kfox1111, for the feedback. I think the middle-ground alternative is reasonable and aligns with what we’ve discussed within the maintainers group.
As an implementation detail, I suggest adding a field to the registered_entries table to store a data blob containing an encoded protobuf message where we can specify this and other flags or options. This approach would allow us to extend the available options in the future without requiring schema changes (though future changes would still need to maintain backward compatibility).
If someone is willing to take this up, it would be great to first work on a draft PR with the main logic changes since there may be some more complexity in the implementation.
@tjons are you still interested in working on this?
I am happy to have a go at this one, unless work has already started @tjons @kfox1111 @rturner3
It's taken me a while, this being my first pass at updating the datastore. As suggested here, I have opened a draft PR to invite initial feedback. Thank for you for your patience.