Problem with 2.222.1 LTS release

[apogrebnyak]

After upgrading to 2.222.1 LTS image, I see a lot of warnings like this:

2020-03-25 18:25:15.671+0000 [id=15]	WARNING	hudson.security.csrf.CrumbFilter#doFilter: Found invalid crumb 1ff86fb7300dfdd80c4763c340895325059c24b153d66cdce11164dd6f21cbdd. If you are calling this URL with a script, please use the API Token instead. More information: https://jenkins.io/redirect/crumb-cannot-be-used-for-script
2020-03-25 18:25:15.672+0000 [id=15]	WARNING	hudson.security.csrf.CrumbFilter#doFilter: No valid crumb was included in request for /user/jenkins-operator/descriptorByName/jenkins.security.ApiTokenProperty/generateNewToken by jenkins-operator. Returning 403.

I saw there was a CVE for previous LTS version (2.204.5). I think this is the result of that CVE fix.

Currently I am able to login into the Jenkins CR when running with default Security Realm and Authorization. However, when switching to LDAP and Role-based Strategy I can no longer log in.

The identical setup works fine with 2.204.5.

[apogrebnyak]

Additional info about LDAP config and role-based authz with 2.222.1.

Looks like the JCasC configuration scripts were not applied at all, and it is still back to default auth/authz, that explains why you cannot login with LDAP creds.

I am able to login with operator creds.

I think communication from operator to cr is completely broken with the new release.

[salluvada]

We need to get a crumb issued first and then call the generateNewToken endpoint to get the token.

So initially call

CRUMB=$(curl <jenkinsURL>/crumbIssuer/api/xml?xpath=concat\(//crumbRequestField,%22:%22,//crumb\) \
-c cookies.txt \
--user '<username>:<password>')

followed by

curl '<jenkinsURL>/user/admin/descriptorByName/jenkins.security.ApiTokenProperty/generateNewToken' \
--data 'newTokenName=kb-token' \
--user '<username>:<password>' \
-b cookies.txt

Source : https://support.cloudbees.com/hc/en-us/articles/115003090592-How-to-re-generate-my-Jenkins-user-token#usingtherestapi

I am going to give a shot at fixing this issue.

[salluvada]

Tested with curl requests and I am able to generate a token...

root@ubuntu-54ccfdd5bd-gcsjz:/test# curl --cookie-jar ./cookie 'http://jenkins-operator-http-example:8080/crumbIssuer/api/json' -u jenkins-operator:vWVmCzSSKxilwV0KIoC6 
{"_class":"hudson.security.csrf.DefaultCrumbIssuer","crumb":"865eec25ae96e3b009263c7fce2d5db7a17944602fd83f2c3e88f028a3192c76","crumbRequestField":"Jenkins-Crumb"}root@ubuntu-root@ubuntu-54ccfdd5bd-gcsjz:/test# curl 'http://jenkins-operator-http-example:8080/user/jenkins-operator/descriptorByName/jenkins.security.ApiTokenProperty/generateNewToken' --data 'newTokenName=test-token' --user 'jenkins-operator:vWVmCzSSKxilwV0KIoC6' -b ./cookie -H 'Jenkins-Crumb:865eec25ae96e3b009263c7fce2d5db7a17944602fd83f2c3e88f028a3192c76' 
{"status":"ok","data":{"tokenName":"test-token","tokenUuid":"1a391f6f-4c68-40b5-963a-95d81b25e6c6","tokenValue":"11e38ece7a3dccff413c35643d93d5f577"}}root@ubuntu-54ccfdd5bd-gcsjz:/test# 

[tomaszsek]

So we have to use https://golang.org/pkg/net/http/cookiejar/ here https://github.com/jenkinsci/kubernetes-operator/blob/master/pkg/controller/jenkins/client/jenkins.go#L153 by default and it should work for both use cases.

[tumevoiz]

Hi @apogrebnyak
Have you solved the issue?

[apogrebnyak]

@jakalkhalili: As stated here #305 (comment) it will be fixed in 0.4.0.
For now you should pin docker container version to 2.204.5 instead of lts.

[tomaszsek]

Fixed in https://github.com/jenkinsci/kubernetes-operator/releases/tag/v0.4.0