Add support for CircleCI tokens

[di]

Description

Similar to #243, CircleCI supports OIDC tokens: https://circleci.com/docs/2.0/openid-connect-tokens/

Also similar to #243, the aud is not customizable: https://circleci.canny.io/cloud-feature-requests/p/customizable-audience-claim-in-oidc-tokens The aud is now customizable: https://circleci.com/docs/oidc-tokens-with-custom-claims/

[znewman01]

CC @nsmith5

[nsmith5]

@zalimeni I see on the Circle roadmap that API tokens getting auto injected into builds will be a think in the future. Is there any chance that these tokens will be usable to grab OIDC tokens with custom claims. IIRC this is how it works in Github actions. There is a token with a default aud but you can request a new one with a different audience inside you build

[fproulx-boostsecurity]

They shipped. so can this be added soon ?
https://circleci.com/docs/openid-connect-tokens
https://circleci.com/blog/openid-connect-identity-tokens/

[nsmith5]

No, they don't support customizable 'aud' yet afaik so we can't support in Fulcio yet. See the attached feature request in canny for details

…

On Fri, Aug 19, 2022, 8:01 PM François Proulx ***@***.***> wrote: They shipped. so can this be added soon ? — Reply to this email directly, view it on GitHub <#591 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC4X2GMA6UHPXBK3VEGVZX3V2BC7PANCNFSM5WGKETSA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[nsmith5]

This work is now planned at CircleCI https://circleci.canny.io/cloud-feature-requests/p/customizable-audience-claim-in-oidc-tokens

[MarshallOfSound]

@di / @nsmith5 Looks like this is getting underway at Circle, wondering if the requirement from fulcio is specifically that aud is exactly equal to sigstore or per the JWT spec can it be an array of audiences where one of them is sigstore?

[nsmith5]

@MarshallOfSound Still marked as "planned" on Canny as it has been for a while...

In any case, we use https://pkg.go.dev/github.com/coreos/go-oidc/v3/oidc#IDTokenVerifier.Verify to verify token which should be conformant to the OIDC Spec

From the spec section 3.1.3.7. ID Token Validation:

The ID Token MUST be rejected if the ID Token does not list the Client as a valid audience, or if it contains additional audiences not trusted by the Client.

So my assumption is that additional audiences will be rejected. Though when you look at the actually implementation, it seems to ignore additional audiences if it finds the the right one at least.

https://github.com/coreos/go-oidc/blob/v3.5.0/oidc/verify.go#L264

Soooo yeah this will work, but I'd caution CircleCI folks from implementing this way has it appears to be outside of OIDC conformance and still has the same security flaws as a fixed audience. If you can only add more and more audience claims the tokens still can't be narrowly scoped to a client basically..

[MarshallOfSound]

@nsmith5 There's definitely movement happening behind the scenes, I'm just trying to make sure that what's being done will be workable / supported by fulcio as that is the main reason we're pushing for customizable audience claims on CircleCI.

Sounds like the array-of-audiences approach although technically will work should probably not work in the future 😅 Thanks for the reference, super helpful 👍

[nsmith5]

😆 Yeah I'm honestly tempted to patch the OIDC library to be closer to the spec. I've you've got an leverage as a customer with them and can push them in a particular way, I'd definitely advise them towards making the implementation as close to the OIDC spec as possible. Better security IMO

[jerdog]

CircleCI has just added customizable audience claims in OIDC tokens =)

https://circleci.com/docs/api/v2/index.html#tag/OIDC-Token-Management

[haydentherapper]

Fantastic! Next step would be to update the OID doc to map claims in the CircleCI identity token to the extensions in Fulcio certs.

[nsmith5]

@jerdog I'm a little tentative about accepting tokens from CircleCI. Unfortunately the implementation only allows adding audiences to the one token issued per-build. If someone configures more than one client / audience in their build it would be clear to Fulcio whether or not the token has come from the pipeline or the other audience / client. I'll copy my example from the Canny here:

As an example, imagine you want to authenticate to service A and service B from your build. In this case you'd set the audience to something like [ "service A", "service B"] on that project and each service should see that it is in the audience list and accept the token. The problem is that if service A gets compromised or is acting maliciously, it can take the token it received from your build and use it to authenticate to service B.

The design makes is a bit more likely that Fulcio could issue code signing certificates to the wrong client and that is a concern to me.

This isn't just a concern for Sigstore, but rather all OIDC clients consuming CircleCI tokens with a list of audiences and is very similar to the original security concern described in the canny issue -- A single hard coded audience has the same security properties that a list of many audiences on one token has.

[jerdog]

I'll pass this on @nsmith5

[MarshallOfSound]

I've passed this on too, this design is actually why I was asked my questions a few weeks ago 😄 Hopefully we get the ability soon to generate multiple per-audience tokens so we can get this ball moving

[takeoutweight]

Hi! I'm Nathan from CircleCI. We're just starting to roll out the ability to configure the aud claim in OIDC tokens at a fine-grained level. It's used in CI like:

export SIG_TOKEN=$(circleci run oidc get --claims '{"aud": "sigstore"}')

All the other claims are as per the $CIRCLE_OIDC_TOKEN_V2. We don't allow any other customization with this mechanism besides the "aud" claim.

Just checking in to see what next steps might look like for getting CircleCI set up as a supported identity provider. I see from Mapping OIDC token claims to Fulcio OIDs there are a number of claims that can map to cert extensions for code signing. We don't currently supply all of these data points in our tokens so I'm guessing we'd be looking at expanding our support for code signing after becoming an IDP, as a follow up?

[fproulx-boostsecurity]

This is indeed officially documented in CircleCI's documentation https://circleci.com/docs/oidc-tokens-with-custom-claims/

So what's next? Add it to Fulcio, then in cosign ?

[haydentherapper]

Yep, if you take a look at the CodeFresh PR, that’s what you’ll need to do. Add the code and map as many token claims to extensions.