Allow claims to be configured

[jglick]

System for configurable JWT claims. Closes #14.

Supersedes #15: you can simply change ${JOB_URL} to ${JOB_NAME} as you prefer.

Supersedes #16: you can add custom claims for things like ${BRANCH_NAME}, or include them in subject in some format.

Precedes #17: IdTokenCredentials.algorithm could rather become a property of IdTokenConfiguration.

While all of these things could be properties of IdTokenCredentials rather than global configuration, I am not confident in the usability of such a system’s security model. As discussed in https://github.com/jenkinsci/oidc-provider-plugin/pull/15#issuecomment-1212091098, this would permit any “disgruntled employee” with folder configuration rights to begin issuing signed id tokens from Jenkins which define completely arbitrary subject or other claims. While the issuer would either be external to Jenkins or, if the default, not be under the attacker’s control, this puts the onus on administrators configuring OIDC-enabled services (Vault, …) to carefully trust only specific issuers, and be aware that tokens issued from Jenkins not at global scope may not be as trustworthy as those issued at global scope. Since it seems unlikely that a single controller would actually need to issue tokens with two different formats for a particular claim, making this global configuration seems safer.

• [X] sketch of system
• [x] enforce valid claim list
• [x] regression: build_number claim supposed to be numeric
• [x] test of GUI
• [x] test of CasC
• [x] test of alternate claims
• [x] form validation
• [x] inline help
• [x] user docs

[LucaPrete]

Can you please also update the docs so users will know how to use this?

[fungusakafungus]

This is looking great so far!

[jglick]

https://github.blog/changelog/2022-10-18-github-actionsopenid-connect-support-enhanced-to-enable-secure-cloud-deployments-at-scale/ heh

[fungusakafungus]

https://github.blog/changelog/2022-10-18-github-actionsopenid-connect-support-enhanced-to-enable-secure-cloud-deployments-at-scale/ heh

Someone leaked this PR to github actions team! We got a mole!

[jglick]

Would anyone interested in this functionality be willing to try a build prior to merge & release? Assuming CI passes, there will be an Incrementals link from which you can download a *.hpi file to install manually in Plugin Manager » Advanced.

[fungusakafungus]

I'd be happy to test in the next few days

[jglick]

Thanks in advance! https://repo.jenkins-ci.org/incrementals/io/jenkins/plugins/oidc-provider/38.va_7394b_f3f646/oidc-provider-38.va_7394b_f3f646.hpi

[kstevena]

@jglick, I have quickly tested your valuable feature without facing issues. Here is what I've tested:

• General & build scoped claims of type string with constant values and substitutions (existing and non existing environment variables)
• Global and folder scoped OpenID Connect token credentials
• JCasC apply & export

[jglick]

Thanks! The test coverage is also reasonably complete, so what I am really interested in is whether the design is practical with a realistic configuration of an actual service such as Vault or AWS.

[fungusakafungus]

Testing it too, setting "primary" claim to ${BRANCH_IS_PRIMARY} and assuming an aws role with a trust policy like

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::<account-id>:oidc-provider/<jenkins-host>"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringEquals": {
                    "<jenkins-host>:primary": "true",
                }
            }
        }
    ]
}

works well and seems useful I'm afraid I wasn't thorough enough with my testing, this trust policy doesn't work

[jglick]

Perfect, that is the sort of thing I was looking for; will release. Please feel free to file PRs updating docs with tested real-world examples.

[LucaPrete]

This is great! Thanks a lot for the effort. Sorry for not being able to contribute as well. I'll give it a try soon as well.

-Luca

Il giorno mar 1 nov 2022 alle ore 14:22 Jesse Glick < @.***> ha scritto:

Perfect, that is the sort of thing I was looking for; will release. Please feel free to file PRs updating docs with tested real-world examples.

— Reply to this email directly, view it on GitHub https://github.com/jenkinsci/oidc-provider-plugin/pull/18#issuecomment-1298503450, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARY7UAWQL5IARFQ6V46JDTWGEKSBANCNFSM6AAAAAAQUVG4GA . You are receiving this because you commented.Message ID: @.***>

[fungusakafungus]

I'm afraid I wasn't very thorough with AWS testing, I had other conditions in the mix as well, and while trying to simplify the test I found out that claim names are not automatically available as condition keys; the list of available condition keys for AWS policies is here: Available keys for AWS web identity federation

This PR is still useful for constructing sub claim differently, I will continue testing and document what's possible and useful.

[bml1g12]

names are not automatically available as condition keys; the list of available condition keys for AWS policies is here: Available keys for AWS web identity federation

@fungusakafungus did you manage to get this working with AWS trust policy? I wonder if there's any way to view what keys are available from cloudtrail or otherwise

[fungusakafungus]

@fungusakafungus did you manage to get this working with AWS trust policy? I wonder if there's any way to view what keys are available from cloudtrail or otherwise

the docs say it's only sub for this combination of systems. I didn't get further than this sadly.

[bml1g12]

@fungusakafungus did you manage to get this working with AWS trust policy? I wonder if there's any way to view what keys are available from cloudtrail or otherwise

the docs say it's only sub for this combination of systems. I didn't get further than this sadly.

Thanks @fungusakafungus - I'm struggling to get even sub to work - any idea why? I have a repo org_name/repo_name so in Jenkins configuttion for Build-scoped claim templates I've configured key: git_url and value: GIT_URL

Then in the trust policy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::xxxxx:oidc-provider/jenkins.hq.scvl.jp/oidc"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringEquals": {
                    "jenkins.hq.scvl.jp/oidc:aud": "sts.amazonaws.com",
                    "jenkins.hq.scvl.jp/oidc:sub": "git_url:https://github.com/org_name/repo-name.git"
                }
            }
        }
    ]
}

But it seems this does not produce a role that can be adopted - any idea why? Or even any idea how I can get debugging logs that might point me in the right direction of the issue.

[bml1g12]

Ah I see what I'm doing wrong, the git_url is a new claim completely seperate to sub. Also ${GIT_URL} isn't be substituted correctly.

Can debug by JWT decoding the AWS Web Identity Token being used

[jglick]

Can debug by JWT decoding

Yes, this is something that should probably be highlighted in docs; example: https://github.com/jenkinsci/oidc-provider-plugin/blob/e313d1fecea64213315f6d3d0ede35b3afa26828/demo/aws/run.sh#L162-L172

(Note that \$ there is escaping for purposes of configuration-as-code YAML; a real Jenkinsfile should use just $.)

You need to be careful, however, that no one has access to the build logs (within an hour of the build running) who cannot be trusted since only the encoded JWT will be masked. In the above example, .. is used to deliberately suppress masking of even the encoded form, again just for demo purposes.

[fungusakafungus]

I use this jq incantation for debugging the token: jq -R 'split(".") | .[0],.[1] | @base64d | fromjson' < $AWS_WEB_IDENTITY_TOKEN_FILE