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

Should staging Fulcio support a permissive OIDC IdP? #1273

Closed
znewman01 opened this issue Jul 12, 2023 · 2 comments
Closed

Should staging Fulcio support a permissive OIDC IdP? #1273

znewman01 opened this issue Jul 12, 2023 · 2 comments
Labels
enhancement New feature or request

Comments

@znewman01
Copy link
Contributor

The Sigstore conformance test suite needs access to some OIDC token to run its tests (which run against Sigstore staging, and include OIDC-based signing flows). GHA (quite sensibly) prohibits access to OIDC tokens for PRs coming from third parties who are not trusted maintainers. However, this means that if we want to use GitHub Actions OIDC (which seems natural, given that our tests run on GHA), only maintainers can run the test suite pre-merge. This could lead to a lot of breakage.

The terrible hack that we've figured out is the extremely dangerous public OIDC beacon: a repo which runs a scheduled workflow that just posts a currently-valid GHA OIDC token for the repo in a public place. This is probably okay, given that nobody should be relying on a token from that repo. But it is a pretty gross hack.

Testing would be a lot easier of Sigstore supported something like justtrustme.dev—an OIDC identity provider that just issues tokens with any subject (or indeed, any claim you want) to anybody who asks. This was created by @eddiezane for demo purposes and comes with no uptime guarantees, but anecdotally appears to work pretty well. Something like this would meet our testing needs, though if we do depend on such a service we should probably run it ourselves under the Sigstore org. justtrustme is open source so that's an option.

@znewman01 znewman01 added the enhancement New feature or request label Jul 12, 2023
@haydentherapper
Copy link
Contributor

This doesn't solve the issue for the conformance suite since it would still want to run against production, correct? Unless they're ok with some instability brought on by staging (it is rarely down, but there is a higher risk and no SLO). Long term, I would love more environments, each with their own root of trust of course:

  • Staging would be bleeding edge with deployments from HEAD
  • Preprod would be like current staging where we'd stage production releases
  • Prod-qual would match the production environment but explicitly be for testing, and in this environment, we could have a more permissive IDP

@haydentherapper
Copy link
Contributor

Closing this out, I think the solution here is more environments, which we aren't set up for at this point.

@haydentherapper haydentherapper closed this as not planned Won't fix, can't repro, duplicate, stale Jul 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants