Skip to content

oidc-discovery-provider file based JWKSSource #6017

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
kfox1111 opened this issue Apr 18, 2025 · 3 comments · May be fixed by #6025
Open

oidc-discovery-provider file based JWKSSource #6017

kfox1111 opened this issue Apr 18, 2025 · 3 comments · May be fixed by #6025
Labels
triage/in-progress Issue triage is in progress

Comments

@kfox1111
Copy link
Contributor

The oidc-discovery-provider can read the JWKSSource material from the server unix socket or workload api. I'd like to be able to read it from a file as well. Would a patch for that functionality be acceptable?

@amartinezfayo amartinezfayo added the triage/in-progress Issue triage is in progress label Apr 18, 2025
@kfox1111
Copy link
Contributor Author

Proposed config options would be:

  • filename
  • poll_interval

kfox1111 added a commit to kfox1111/spire that referenced this issue Apr 22, 2025
This enables the oidc-discovery-provider to read the trust bundle from a
file.

Fixes: spiffe#6017

Signed-off-by: Kevin Fox <Kevin.Fox@pnnl.gov>
@kfox1111 kfox1111 linked a pull request Apr 22, 2025 that will close this issue
3 tasks
@sorindumitru
Copy link
Collaborator

@kfox1111 Could you add some details about the need for this new configuration mode? Are the two existing modes, spire-server api socket and workload api socket, not sufficient?

@kfox1111
Copy link
Contributor Author

kfox1111 commented Apr 23, 2025

Yes, the existing two are not sufficient. I have a need for running the helm chart in server only mode as a non cluster-admin but still in a scaleable way. I also need to ensure things are hardened as much as possible, so no extra node attestors if possible. This means the csi driver and workload agent are unavailable as they need cluster privilege, having an extra agent per oidc-discovery-pod as a sidecar would be problematic, and coupling the oidc-discovery-provider into the server pod itself is also undesirable for scaling and spire-ha-agent support.

The idea here is to be able to use the spire k8s bundle publisher to upload the full spiffe formatted trust bundle, and then have the oidc-discovery-provider consume the configmap. Very simple result. k8s shuttles the trustbundle from the spire server to the discovery provider automatically.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
triage/in-progress Issue triage is in progress
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants