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

Add Gitpod as a trusted ID token provider #1176

Open
ChevronTango opened this issue May 19, 2023 · 4 comments · May be fixed by #1177
Open

Add Gitpod as a trusted ID token provider #1176

ChevronTango opened this issue May 19, 2023 · 4 comments · May be fixed by #1177
Labels
enhancement New feature or request

Comments

@ChevronTango
Copy link

Description

Gitpod is an automated workspace solution currently trying to sign all of the commits that its users make automatically using sigstore. To do this they plan on generating JWT tokens using a command line tool, and passing those via Gitsign to fulcio for it to return a signing certificate.

To enable this end to end, Gitpod needs to be added to Fulcio as a trusted identity provider so that its tokens are accepted and a certificate can then be issued safely.

an example token (currently missing the email claims), generated from gp idp token --audience sigstore looks like the following

{
  "iss": "https://api.gitpod.io/idp",
  "aud": [
    "sigstore"
  ],
  "azp": "sigstore",
  "c_hash": "9Z96rjksu24zNCIsHHm5hQ",
  "exp": 1684520711,
  "iat": 1684517111,
  "auth_time": 1684517111,
  "sub": "https://github.com/ChevronTango/cosign",
  "name": "ChevronTango"
}

Can https://api.gitpod.io/idp be added as a trusted issuer so that all users within gitpod can use the inbuilt mechanisms to sign their commits.

@haydentherapper
Copy link
Contributor

Hey, thanks for opening this. To confirm, these tokens represent user identity (email), and not a machine/CI identity? Context: https://github.com/sigstore/fulcio/blob/main/docs/oid-info.md#requirements-to-support-signing-with-cicd-workload-identities

This is a straightforward change if so. Can you add a configuration under federation/external, and update config/fulcio-config.yaml? Type will be “email”.

If this is a ci identity, there’s more work to do which we can chat about, but I don’t believe it is.

@haydentherapper
Copy link
Contributor

We also have a list of requirements for new providers, it’s a WIP but if you could, can you take a look and answer these questions - #397

@haydentherapper
Copy link
Contributor

One more question: is this something that will be automated or where a user is present? I ask because we have two options for where to add the new provider. One is directly in fulcio’s configuration, what I noted above. The other option is in our federated identity provider, but this initiated an OpenID Connect authentication with the user, which requires user presence.

@ChevronTango
Copy link
Author

Thanks @haydentherapper , I'll try and answer the questions as best I can, but I'm a user of Gitpod trying to help the project move along, rather than a member of it's development team.

The idea is to have all commits within Gitpod signed automatically by the user who has the session open, without any additional work by that user. Because the user has already logged into Gitpod and authenticated with their chosen IDP, it stands to reason that they do not need to reauthenticate again just to sign their commits. The session they are in should be enough.

Gitpod is a web IDE, not a CI platform, so the user will be present. That being said, we want to avoid any additional UI interactions like a redirect to DEX if we can help it (we could do that now if we wanted). Gitpod has already authenticated the user and will provide a JWT token of the Email type so that Fulcio and Gitsign can validate it.

if we get this right, then any user coding in a Gitpod workspace will automatically have all of their commits signed, which from an industry supply chain attack perspective is a massive win, given the huge number of users on Gitpod. The reason I'm advocating for this strongly is because I am a big proponent of good security by default for as many users as possible.

I'll take a look a look at the config file update, and we can discuss any additional questions on Gitpods viability in the MR.

@ChevronTango ChevronTango linked a pull request May 19, 2023 that will close this issue
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

Successfully merging a pull request may close this issue.

2 participants