Skip to content
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

DisableTrustOnFirstUse option for OIDC provisioner #2169

Open
siiimooon opened this issue Feb 16, 2025 · 0 comments
Open

DisableTrustOnFirstUse option for OIDC provisioner #2169

siiimooon opened this issue Feb 16, 2025 · 0 comments
Labels
enhancement needs triage Waiting for discussion / prioritization by team

Comments

@siiimooon
Copy link

siiimooon commented Feb 16, 2025

Hello!

  • Vote on this issue by adding a 👍 reaction
  • If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Issue details

I would like the option DisableTrustOnFirstUse for the OIDC provisioner too, just like the cloud provisioners (Azure, AWS, GCP). Ref.
https://github.com/smallstep/certificates/blob/master/authority/provisioner/azure.go#L117

Why is this needed?

I have integrated Smallstep CA with my Kubernetes environment, which has a OIDC-backed service account issuer. This enables my Kubernetes workloads to fetch certificates based on their service account token. The OIDC provisioner is brilliant for this purpose, as it fetches the signing key dynamically from the cluster OIDC endpoint (rather than hardcoding the service account signing key using the K8SSA provisioner). Sometimes the Kubernetes-based workloads crash and restart, but the service account token is not rotated on a container restart - forcing me to reschedule the error-prone pods to make it obtain a new and unused token. Allowing reuse of a token would simplify operations. Token reuse should still be disallowed by default (as-is), but possible to allow in scenarios where one can accept the risk.

If the change sounds reasonable, I would be happy to file PRs with the change. AFAIK, this would require changes in three repositories (smallstep/certificates, smallstep/linkedca, and smallstep/doc).

@siiimooon siiimooon added enhancement needs triage Waiting for discussion / prioritization by team labels Feb 16, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement needs triage Waiting for discussion / prioritization by team
Projects
None yet
Development

No branches or pull requests

1 participant