Fwd: Running jenkins/jnlp-agent-* Docker images as non-root user

[Damien Duportal]

Cross-posting to this mailing list :)

---------- Message transféré ---------
De : Damien Duportal <Inconnu>
Date : mercredi 20 janvier 2021 à 18:10:45 UTC+1
Objet : Running jenkins/jnlp-agent-* Docker images as non-root user
À : Jenkins Developers <Inconnu>

Hello dear Developers, Contributors and (eventually) users!

The issue https://issues.jenkins.io/browse/INFRA-2879 is making a proposal for a breaking change in the library of Docker images ("jenkins/jnlp-agent-*") coming from the repository https://github.com/jenkinsci/jnlp-agents .

The rationale of this change (why running a container as non root) is not expected to be discussed in this thread (please use the JIRA issue), but:

1. "Should we do this change"? As it even questions the reasons why we provide and maintain this set of images. For instance "jenkins/jnlp-agent-alpine" would be totally deprecated.

2. And if yes, "what is the process to communicate and apply a breaking change?". Is there a standard procedure to go trough the mail/twitter/IRC/etc. channels? We were thinking of adding documentation (README of the repo + README of the images in the DockerHub + comments in the respective Dockerfiles) and writing a blog post. Is there something else?

As the documentation for these image is scarse, it is hard to evaluate the impact. If you have any knowledge on how it is being used (outside the Jenkins project's infra.), could you share it to help us?

Thanks in advance!

Damien DUPORTAL

[Oleg Nenashev]

Hello,

Not running images as root is definitely a positive change for the project. These images are very generic, and I can imagine many users running them without taking the security consideration into account

I would like to note that https://github.com/jenkinsci/jnlp-agents are not very "official" in terms of the level of support/compatibility provided by Jenkins. Of course we would be interested to keep compatibility, but it is not an immediate blocker. Commonly we announce breaking changes via Jenkins blog + social media. Example from the last spring: https://www.jenkins.io/blog/2020/05/06/docker-agent-image-renaming/

One of the ways to "keep" compatibility is to actually introduce a new set of images. It is a good opportunity to get rid of the obsolete "jnlp" prefix. So we could keep the current images as is and to introduce "inbound-agent-ruby" which does not run as root.

Best regards,

Oleg

--
You received this message because you are subscribed to the Google Groups "Jenkins Infrastructure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkins-infr...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/jenkins-infra/b709edf3-7021-4de2-9a88-013204d7e317n%40googlegroups.com.

[Kara de la Marck]

Hi all,

This is a follow up email to Damien’s and Oleg’s emails.

As per Oleg’s suggestion we will be introducing a new set of images, and getting rid of the obsolete “jnlp” prefix, replacing it with “inbound-agent”.
In addition, to avoid confusion and conflicting names with the existing Jenkins/inbound-agent (https://hub.docker.com/r/jenkins/inbound-agent), we will publish them in their own group. These agents have a different purpose than the inbound-agent base image, although they do copy its agent.jar file and other elements. As such we have decided to move the new images into the namespace ` jenkinsciinfra/` on Docker Hub. See discussion on PR: https://github.com/jenkinsci/jnlp-agents/pull/23

In addition, please note that there will not be an agent-alpine image in this new set, eg, no new `jenkinsciinfra/inbound-agent-alpine` image. In practice this means the alpine-agent will be deprecated.

The alpine version, `Jenkins/jnlp-agent-alpine` is currently defined in ci.j.io configuration for aci-alpine. However, it doesn’t appear to be used, see discussion on: https://github.com/jenkinsci/jnlp-agents/pull/24

If you have any concerns regarding these changes please let us know!

Best wishes,
Kara

[Tim Jacomb]

Why move to jenkinsinfra?

That’s normally just for images used in the Jenkins infra project, whereas the Jenkins images are ones produced for the community

To view this discussion on the web, visit https://groups.google.com/d/msgid/jenkins-infra/1b86b9cb-f28d-44cc-be05-19f5db9cc98fn%40googlegroups.com.

[Oleg Nenashev]

Right, Jenkins production images are usually hosted on Trusted CI. Though nothing blocks from using release instance in principle

To view this discussion on the web, visit https://groups.google.com/d/msgid/jenkins-infra/CAH-3Bie43it2pp5go_z0xXA5DT_ZhDewFqMFBQ-wnrA-rZuUJQ%40mail.gmail.com.

[Tim Jacomb]

I have no issue with them not being released from trusted ci, it's more why move from the 'jenkins' docker hub organisation,

To view this discussion on the web, visit https://groups.google.com/d/msgid/jenkins-infra/CAPfivLCirG8UA7CDRcg_R96krzzMzVchRJsE3L5anEERSLQJUA%40mail.gmail.com.

[Richard Bywater]

I might have missed something along the way so apologies if I'm looking in the wrong direction but is there somewhere that describes the purpose of these agents? Based on reading the README of the repo, I thought that they were consumer used images for the purposes of easily consuming build technologies like Maven/Node but then in a comment on the PR it says "These agents have a different purpose than the inbound-agent base image. I think they should be published into a separate prefix." so I'm confused as to their purpose?

Richard.

To view this discussion on the web, visit https://groups.google.com/d/msgid/jenkins-infra/1b86b9cb-f28d-44cc-be05-19f5db9cc98fn%40googlegroups.com.

[Richard Bywater]

This is sort of where my previous question would be heading if the answer is that yes they are for end consumers. Right now we have enough issues trying to convince the security folk that using Jenkins images from Dockerhub is safe and am worried that if the images were then coming from another organisation on Dockerhub it makes it harder to see them as official offerings of the Jenkins project.

If they *do* get moved to a new org (not sure why they would need to be), however, please don't call it jenkinsciinfra as that is way easily confused with jenkinsinfra...

Richard.

To view this discussion on the web, visit https://groups.google.com/d/msgid/jenkins-infra/CAH-3Bif1ZAz0n8WGEKd4wZeCj1E6q-LRJcJc7A-%3DLVtFYfzcWg%40mail.gmail.com.

[Olblak]

I might have missed something along the way so apologies if I'm looking in the wrong direction but is there somewhere that describes the purpose of these agents?

I think this thread highlights the confusion around those images. And I guess the main question to answer is, do we provide those images to the community or are they only used for internal purposes like from ci.jenkins.io

If we consider them for internal usage only then those images need to move to the "jenkinsciinfra" Dockerhub organisation, like every other image that we build for our internal needs. Otherwise, let's keep them on the jenkins organisation.

Regarding where we build them,  IMHO, it doesn't really matter, I would be in favor to not use trusted.ci .

If they *do* get moved to a new org (not sure why they would need to be), however, please don't call it jenkinsciinfra as that is way easily confused with jenkinsinfra...

  This organisation already exist https://hub.docker.com/orgs/jenkinsciinfra, and used for every stuff related to the jenkins infrastructure

To view this discussion on the web, visit https://groups.google.com/d/msgid/jenkins-infra/CAAy0hwettUrmfm39iAsWZ80_MQxmpbFNXNCNan5f42me1BVF5A%40mail.gmail.com.

[Damien Duportal]

Hello 👋

Interesting thread, it was worth it to ask the questions. Thanks all for this shared knowledge and feedbacks.

Considering all the feedbacks, what do you think of the following plan:

• Let’s keep the depreciation of the images "jenkinsci/jnlp-agent-*" as the parent image "jenkins/jnlp-agent"  has been deprecated as well.
• It means that the existing images "jenkinsci/jnlp-agent-*" won’t be updated anymore, and that the "non root" (and futur) change(s) won’t break any current usage.
• As https://issues.jenkins.io/browse/INFRA-2879 is a mandatory + breaking change for the infra, we apply it to a new set of images "jenkinsciinfra/inbound-agents-*"
• It means that the current build process is kept as it, except for the naming change + un-root change.
• With this change applied, the Jenkins Infra team would be able to update ANY usage on ci.jenkins.io, infra.ci.jenkins.io, and any other infra asset, with these new images, baked for this specific need.
• Finally, if the community expresses a need to have an official set of images (which would be "inbound agent with a custom common toolset"), then we can totally add aliases name "jenkins/inbound-agent-*" and nothing stops us to push the same image in both repositories.
• The problem of maintaining such a collection is that it leads a big maintenance overhead, leading to a lot of issues (out of date assets, bad practises, etc.). 
• Adding "back" these images should trigger a discussion of the dimensions to be supported:
• base OS (alpine 3.13, debian:jessie, windows:nanoserver, alpine 3.12, etc.)
• JDK used (OpenJDK8, AdoptOpenJDK11, etc.)
• Jenkins Core version (LTS, weekly, 2.X.Y, etc.)
• Jenkins Agent’s Core dependencies (entrypoint script and JAR file paths, bash, git, git lfs, etc.)
• Tool to be used (Maven 3, Golang 1.15, Golang 1.16, python3, etc.)
• Tools specialization (maven’s settings.xml, npm with NodeJS, pip or setuptools with python)
• We might want to recommend recipes instead of cooked meal here: Maybe the images (e.g. the "cooked meal"- could be replaced by a documentation recommending to manage your own images through supported Dockerfiles (e.g. the "recipes").

What do you think?

Damien D.

You received this message because you are subscribed to a topic in the Google Groups "Jenkins Infrastructure" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkins-infra/DjUK9Ys82Mo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkins-infr...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/jenkins-infra/49d93b84-b55e-4a27-8d82-73bc1e45c923%40www.fastmail.com.

[Tim Jacomb]

It appears some of those images are community contributed, at least the dotnet and powershell ones

I don't understand the reason to move them to jenkinsciinfra, you can still update them on the jenkins dockerhub organisation.

Whether we want to trim the images back / require an image maintainer / ask people to maintain them out of tree is a question I support.

Thanks

Tim

To view this discussion on the web, visit https://groups.google.com/d/msgid/jenkins-infra/32A7545C-E03D-4006-AF01-BD5DA345DFCD%40gmail.com.

[Damien Duportal]

In order to not force any community decision as there is no easy consensus on this, and while the Contributor summit happens,

but to ensure that the initial "un-root" issue will be fixed in the Jenkins Infrastructure,

we have forked the jenkinsci/jnlp-agents repository to https://github.com/jenkins-infra/docker-inbound-agents/ , which pushes images to the jenkinsciinfra's DockerHub account.

By doing this, we were able to apply any changes required only by the infra without impacting existing community users, and without forcing any direction for the jenkinsci/* assets.

This fork is built from Kara's work on the PR https://github.com/jenkinsci/jnlp-agents/pull/24, and is using the infra.ci.jenkins.io 's Kubernetes agents (linting, building, testing and deploying without Docker for security concerns).

Any feedback is welcome of course!

Damien