https://github.com/jenkinsci/docker is the repo for the controller images
there are also agent images at jenkinsci/docker-agent jenkinsci/docker-inbound-agent and jenkinsci/docker-ssh-agent
It should have a signup link for creating an account
FYI, those will get triaged by the Jenkins security team and assigned to the correct people
The security project is generally closed off so that those issues are not public
Following up on this discussion - my security issue was closed - opinion was its not jenkins problem its Debians problem :facepalm:
but I did some more testing regardless -
JDK11 - 2.267 - 13 Medium findings + 89 others (Debian Stretch based)
Alpine - 2.267 - no findings - container is clean
Centos (8) - 2.267 - no findings - Container is clean
Default jenkins/jenkins - 2.266 - 9 high - 17 medium - 37 low - 70 informational - (Deb stretch 9.13)
These results are all with AWS ECR scanning which uses Clair scan rules
We are looking at migrating to buster as the default image in the near future
Yes. I would like to include the switch to buster as part of the JEP that I owe for Docker platform support. One of the principles is that we define a rule that causes us to stop supporting an operating system when the upstream provider stops supporting it. The other rule idea I had was to apply the concept of a "maintainer" to each Docker image with the same type of rules as we use for "adopt a plugin".
None that I recognize. The most notable difference between Alpine and every other distribution is the C library. Alpine uses musl, almost all other distributions use glibc. There are interesting and distracting differences in DNS resolution between musl and glibc, among other differences.
Deb 9.13 would explain the ssh shenanigains with the aws ec2-plugin
Random thought sorry
so slim reports out almost the same findings as jdk11
the finding delta between default on deb9 and slim/JDK11 onDeb 10 is likely the lesser packages
id have to dig deeper and do a side by side
clair is super easy to setup though
I'm not on the 'jenkins' docker org
so i think no we aren't
and unsure
I have an issue with combining the Jenkins Kubernetes Plugin with the Kubernetes Cluster Autoscaler. Jenkins always injects kubernetes.io/os: linux as node selector, but this isn't supported properly when autoscaling instances from 0.
How can I tell the Jenkins Kubernetes Plugin to not set any nodeSelector? I tried setting yamlMergeStrategy: override() and specifying in the yaml that nodeSelector: {} should make it an empty dict, but Jenkins still injects its additions. I can of course explicitly set the nodeSelector os, but setting it to something other than linux is only even worse, including "" or null, which still lead to it being created with the selector, just with an unfullfillable operating system selector.
Does anyone have an idea how I could specifically unset it, or force jenkins to not add stuff I don't want it to add?
How can I tell the Jenkins Kubernetes Plugin to not set any nodeSelector? I tried setting yamlMergeStrategy: override() and specifying in the yaml that nodeSelector: {} should make it an empty dict, but Jenkins still injects its additions. I can of course explicitly set the nodeSelector os, but setting it to something other than linux is only even worse, including "" or null, which still lead to it being created with the selector, just with an unfullfillable operating system selector.
Does anyone have an idea how I could specifically unset it, or force jenkins to not add stuff I don't want it to add?