-
Notifications
You must be signed in to change notification settings - Fork 502
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
Comments
Proposed config options would be:
|
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 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? |
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. |
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?
The text was updated successfully, but these errors were encountered: