OpenID Configuration Discovery Endpoint (just the endpoint) #18691
Conversation
schmichael
force-pushed
the
f-oidc-disco
branch
from
a99bc5b
to
54f9088
Compare
| - `oidc_issuer` `(string: "")` - Specifies the Issuer URL for [Workload | ||
| Identity][wi] JWTs. If set the `/.well-known/openid-configuration` HTTP | ||
| endpoint is enabled for third parties to discover Nomad's OIDC configuration. | ||
| Once set `oidc_issuer` *cannot be changed* without invalidating Workload |
There was a problem hiding this comment.
How bad would it be for this config to drift across servers, like a typo or an old machine coming back up for some reason?
There was a problem hiding this comment.
Very bad. All JWTs would randomly fail (except when used with Nomad because at least for now we don't bother checking the issuer: if the signature is valid and the alloc is live, we're happy).
Moving this state to Raft prevents that issue nicely, and I suppose we could refuse to overwrite existing non-empty values unless a -force or -i-know-what-im-doing flag is set... 🤔
I assumed the config file approach might be easier to synchronize across the multiply places that need to agree on this value (Nomad server configuration, the proxy you're putting in front of the OIDC Discovery endpoint, and the consumers of the discovery endpoint such as AWS IAM OIDC Provider). I'm not sure though. Opinions welcome! 🤔
There was a problem hiding this comment.
Yeah, I was wondering about storing this in state. I don't have any strong opinions, and I don't know if we have any prescriptive guidance of what should go where 🤔
Some aspects I just pulled out of thin air:
| Config file | State |
|---|---|
| Required on agent start | Not required on agent start |
| Specific to each node | Must be the same in all nodes |
| Requires restart to apply change | Can be changed live |
So I feel like this falls into the "state" category? But I also don't feel strongly about my table either 😅
There was a problem hiding this comment.
A lot of the WI related configuration falls onto that right-hand side of the table (ex. all the identity blocks for Consul and Vault configs). I'd love for us to ship some kind of comprehensive server (and client!) configuration management tooling. But I also think that design is something we should work out for a post-1.7 release.
There was a problem hiding this comment.
Yeah, a more holistic strategy for configuration management would be great!
I'm good with the changes here as they are, I just smelled a potentially bad footgun and wanted to confirm it was indeed a bad problem 😅
Co-authored-by: Luiz Aoqui <[email protected]>
Co-authored-by: Luiz Aoqui <[email protected]>
Added the OIDC Discovery
/.well-known/openid-configurationendpoint to Nomad, but it is only enabled if theserver.oidc_issuerparameter is set. Documented the parameter, but without a tutorial trying to actually use this will be very hard.I intentionally did not use https://github.com/hashicorp/cap for the OIDC configuration struct because it's built to be a compliant OIDC provider. Nomad is not trying to be compliant initially because compliance to the spec does not guarantee it will actually satisfy the requirements of third parties. I want to avoid the problem where in an attempt to be standards compliant we ship configuration parameters that lock us in to a certain behavior that we end up regretting. I want to add parameters and behaviors as there's a demonstrable need.
Users always have the escape hatch of providing their own OIDC configuration endpoint. Nomad just needs to know the Issuer so that the JWTs match the OIDC configuration. There's no reason the actual OIDC configuration JSON couldn't live in S3 and get served directly from there. Unlike JWKS the OIDC configuration should be static, or at least change very rarely.
This PR is just the endpoint extracted from #18535. The
RS256algorithm still needs to be added in hopes of supporting third parties such as AWS IAM OIDC Provider.