Return an error if an SDS client asks for resources that don't exist.

[JonathanO]

This will reject an SDS client if it requests resource names that don't exist.

This is a solution for SDS clients getting "stuck" if attestation fails temporarily due to some local problem (e.g. k8s attestation taking too long.)

This may cause problems if anyone is relying on a configuration where it is expected to request multiple identities/bundles in the same SDS session, some of which do not exist (yet.)

fixes #1230

[JonathanO]

The alternative to this PR would be to simply hang up after attestation (or on first request) if no identities were issued. That would also solve the problem, and, unlike this PR, it matches the behaviour of the workload API. But I am concerned that there could be people depending on having workloads with no identities retrieving trust bundles via SDS, which such a change would break. If that isn't actually a supported use case then I'll close this PR, and raise a new one with the simpler fix.

[azdagron]

The alternative seems interesting and I'd probably be for it except the Workload API specification has recently gained an RPC that can be used to fetch X.509 bundles (optionally without requiring the workload to be attested) in order to support verifying SPIFFE IDs from a trust domain without having to actually belong to the trust domain (we have yet to implement this in SPIRE), so from a behavior parity standpoint, I think it makes most sense to continue allowing a bundle to be returned to an unauthenticated workload.

[evan2645]

TL;DR: I think this approach is alright for the time being

I'm still not in love with the whole unregistered workload api consumer thing... Putting that aside, this SDS thing needs to be fixed one way or another. I've considered this approach vs the alternative (which feels better on the surface), and ultimately I agree with @azdagron and @JonathanO - this approach seems unlikely to fail in strange ways, and also unlikely to introduce pain for existing consumers that may be using the agent in surprising ways. At the same time, it doesn't prevent us from moving to the alternative behavior in the future, so... 👍

[azdagron]

This looks good to me. I left a few nitpicks to make the code a little more terse but don't feel obligated to fix them. Happy to merge without.

[azdagron]

Thanks, @JonathanO !