Allow DelegatedIdentity API clients to subscribe by PID

[bleggett]

This is designed to provoke discussion around the DelegateIdentity API changes required for spiffe/spire#5019

This is following the "pass PIDs" approach settled on in the RFC doc: https://docs.google.com/document/d/1A1oQHuR6z3bvQtXN17r2EwBr5lazGGPbUPkxoURAAh4/edit

This assumes that the caller/client is ensuring that the PID is not recycled for the duration of the stream/call, using pidfd or similar.

Looking for the following feedbacks:

• Is this additional functionality a good fit for the DelegateIdentity API or should we add a new API? I think we should just extend DI.

• Do we object to supporting stream/subscriber based APIs? I think we should support them, even though the PID recycling protection requirement puts more onus on the client.

• Do we want to do this for both JWT and x509 SVIDs? I assume so, and added new calls for both of the ones that previously required selectors.

• Rather than make currently-required fields optional (selectors), I added parallel calls with new, parallel messages/fields. Do we want to do it like this, or do we want to use a single message/call and deprecate the old fields?

The impl side of this is here: spiffe/spire#5272

[azdagron]

Thanks for this @bleggett. We discussed this a bit and I think at this time the preference is to:

1. Extend the existing RPCs instead of creating new ones
2. Use a oneof to either provide selectors or the pid

[bleggett]

Thanks for this @bleggett. We discussed this a bit and I think at this time the preference is to:

1. Extend the existing RPCs instead of creating new ones
2. Use a oneof to either provide selectors or the pid

Okay, I'm fine with that. Will redo it along those lines.

Thanks for getting back!

[bleggett]

Use a oneof to either provide selectors or the pid

@azdagron There's one gotcha with this - you cannot use repeated fields in a oneof. And the existing selectors are repeated.

This could be fixed by creating a new message for the selectors, nesting the repeated selectors in that message, and using oneof {message, pid}

The problem with this is that it will break back compat for people using this API that already use the selectors as-is.

I don't mind that much myself, but I was originally trying to avoid altering the existing API in any way.

Thoughts?

[azdagron]

Oh that's right. We need to preserve backcompat. I think the best option is to not leverage oneof at this point and just check for mutual exclusivity in the handler implementation.

[azdagron]

Looks good overall. Just a few small nitpicks.

[bleggett]

@azdagron all right, suggestions applied.

I also updated spiffe/spire#5272

Note that one consequence of sharing the same message and not using oneof is that an "unset" PID is naturally protobuf'd to 0: https://github.com/spiffe/spire/pull/5272/files#diff-1007e43f9ac81915b4fd0f98b5a937ae07f2d12c5d20fa69a2919788663c868eR121

0 is technically a valid PID, and with this approach we basically cannot attest a PID of 0, but I cannot imagine how or why SPIRE might need to do that given that PID 0 is special, so I don't think it's a big deal.

[azdagron]

Yeah, AFAIK, no userspace process will have pid 0, so I think that's a practical tradeoff.

[bleggett]

Ty @azdagron and others!