Add GitLab Support for Ambient Credential Detection

[developer-guy]

Description

There are some environment variables provided by GitLab to the runner environment which we can use to authenticate.

CI_JOB_JWT: A RS256 JSON web token to authenticate with third party systems that support JWT authentication, for example HashiCorp’s Vault.

CI_JOB_JWT_V2: alpha: A newly formatted RS256 JSON web token to increase compatibility. Similar to CI_JOB_JWT, except the issuer (iss) claim is changed from gitlab.com to https://gitlab.com, sub has changed from job_id to a string that contains the project path, and an aud claim is added. Format is subject to change.

CI_JOB_TOKEN: A token to authenticate with certain API endpoints. The token is valid as long as the job is running.

👉 https://docs.gitlab.com/ee/ci/variables/predefined_variables.html

cc: @dlorenc @Dentrax @orhun

[dlorenc]

There's some discussion over here: sigstore/fulcio#243

The tokens are currently missing an audience so we can't use them directly. It sounds like that might be in progress though!

[mattmoor]

Yeah, we should NOT do this before the public Fulcio supports gitlab via --identity-token, otherwise it'll create annoying failure modes.

[marshall007]

If possible, I think using CI_JOB_TOKEN is probably the best medium-term approach.

If Fulcio is passed our CI_JOB_TOKEN it can make an API call to GET <gitlab-server-url>/api/v4/job to tretrieve the job definition for the given token. See docs:

https://docs.gitlab.com/ee/api/jobs.html#get-job-tokens-job

One desirable property of the CI_JOB_TOKEN is that we automatically revoke its access as soon as the job is terminated. Its access is also limited to API endpoints that are specifically relevant to the CI job it is created for.

I understand this is still not as ideal as crafting a JWT with a specific aud claim, just noting that we have some other mechanisms in play that limit the replay-ability of CI_JOB_TOKENs.

---

I'm pushing on adding support for custom aud claims in CI_JOB_JWT_V2, but it's going to take some time as it will involve extending our CI job YAML definitions and deprecating some old behavior (both user-facing and potentially breaking changes). Our tentative plan is to formalize CI_JOB_JWT_V2 and deprecate CI_JOB_JWT in v15.0.

To reiterate, CI_JOB_TOKEN is gonna be the most compatible solution for the time being because (1) people run a different versions of GitLab and (2) even in v15.0 it's very probable that what I just described will be behind feature flags due to the breaking changes, which may not be enabled on all GitLab instances at first.

[edit]: this is being tracked here on our side: https://gitlab.com/gitlab-org/gitlab/-/issues/294291

Let me know if this is a workable solution or if you have any questions!

[mattmoor]

to tretrieve the job definition for the given token

@marshall007 I am curious what you anticipate Fulcio would do with this information?

Its access is also limited to API endpoints that are specifically relevant to the CI job it is created for.

This is the aspect I'm struggling with, since we're talking about granting access to sign against Fulcio without that being explicitly declared. 😅

To reiterate, CI_JOB_TOKEN is gonna be the most compatible solution for the time being

Yeah, I totally get it and empathize with the goal, but I still am not seeing how we differentiate between CI_JOB_JWT[_V2] today (or with legacy installations) and the same in the future where a user has NOT opted into aud: sigstore? 🤔

The scenario I'm imagining is: in a hypothetical future v18.0 a user does NOT want their job signing against Fulcio (no aud: sigstore), but the token ends up in the hands of an attacker. How does Fulcio distinguish these tokens from v15.0 and earlier versions?

[mattmoor]

Here's a thought, which might be a decent compromise, since my major issue is folks opting into the dangers here...

We could teach Fulcio to do what you suggest, which would enable folks to opt-in to this functionality in their own private Fulcio instances.

However, for the "public good" Fulcio instance, we would continue to require aud: sigstore. I think we'd want the ambient functionality (which is entirely sugar) to match our posture with public Fulcio.

Folks using their own Fulcio could still:

cosign sign --fulcio-url ... --identity-token ${CI_JOB_JWT} IMAGE

However, this would only work with CI_JOB_JWT_V2:

cosign sign IMAGE

[marshall007]

@mattmoor to be clear CI_JOB_TOKEN is an opaque token, not a JWT. So in this case, rather than verifying the integrity of a JWT and referencing metadata from the parsed claims, I was saying that Fulcio could both validate this opaque token and get job metadata by calling our API endpoint, for example:

curl --header "Authorization: Bearer $CI_JOB_TOKEN" "https://gitlab.com/api/v4/job"

I can fully appreciate not wanting to "teach" Fulcio how to interpret GitLab-specific opaque job tokens. I was just presenting it as a possible backwards-compatible solution for all the < v15.0 GitLab instances out there (including gitlab.com at the moment).

[haydentherapper]

Completed by @wlynch