[oidc-discovery-provider] spiffe cert support

[kfox1111]

There are a bunch of ways to configure the cert on the service. One option missing would be to use the workload api to grab a cert and use that. We're already doing that using the spiffe-helper but adds a lot of potential unneeded complexity to the setup.

[azdagron]

Can you clarify the use case here? I think what you're asking for is that the OIDC Discovery Provider use a server certificate provided by the Workload API? So callers would need to have a bundle to authenticate that SVID? Seems a little chicken-and-eggy to need a bundle to authenticate the connection to the provider in order to obtain the bundle material presented by the provider?

[kfox1111]

Thats what I'm asking for yeah. We have some configs where we
spire-helper -> certs -> spiffe-oidc-discovery-provider

It would be much easier to manage if it was naitively supported.

The chicken and the egg problem is real, but there are solutions to that too, such as running the spire-agent on the host to fetch the spiffe x509 bundles for validation. I'm doing that for the Kubernetes integration stuff I've been working on.

[azdagron]

Hey @kfox1111, do you have an arch diagram or something that spells out the use case clearly that you can share (either here or privately in slack with the maintainer group)? Before we consider taking this we'd like to see if there are alternatives.

[azdagron]

After some discussion we're leaning towards not taking this feature as long as a viable workaround exists. Maybe an alternate path forward is to try and effect a change upstream in Kubernetes that provides an alternate path for obtaining the JWKS used to validate tokens (e.g. from disk?).

[kfox1111]

I asked the sig-auth channel already. They said any further changes in that part of the code are highly unlikely.

[evan2645]

@kfox1111 can you propose some config changes to support this feature? Wondering what that will look like and the experience around it.

[kfox1111]

There are two configurations currently:
https://github.com/spiffe/spire/blob/main/support/oidc-discovery-provider/config.go#L57-L63
acme and providing a cert/key.

Thinking a new option that is something like:
TLSUseSPIFFE = true/false

If true, it would use https://github.com/spiffe/spire/blob/main/support/oidc-discovery-provider/config.go#L71 (WorkloadAPIConfig) to get the tls key/cert in addition to the jwks.

[sorindumitru]

Might be a bit more future proof and consistent with the other config type to use a struct similar to ACME/ServingCertFile in case we need to add aditional configuration for this in the future (e.g. maybe using a workload api socket from a different trust domain, so separate from the other workload api socket). I don't know if that's likely to happen, though.

[amartinezfayo]

We have discussed this within the maintainers group and we think that we may add a new section that would allow to configure fetching the certificate from the Workload API.
Something like:

serving_cert_source "acme" {
   ...acme attributes
}

serving_cert_source "cert_file" {
   ...cert_file attributes
}

serving_cert_source "workload_api" {
   ...workload_api attributes
}

This would allow to configure this in a backwards compatible way. We can deprecate the acme and serving_cert_file settings in favor of this config.

[amartinezfayo]

Since we have an agreement on the config changes, I've labeled this to be in the backlog. Thank you @kfox1111 for bringing this up, we will be happy to take contributions for this.