922191 - HTTP authentication on ci.mozilla.org for URLs with "build" in them is silly

Status: RESOLVED FIXED

(Infrastructure & Operations :: IT-Managed Tools, task)

Description

[Gregory Szorc [:gps]]

There is some kind of rule on the HTTP server for https://ci.mozilla.org/ that requires HTTP authentication for URLs ending with "build." Attempts to access said URLs will result in the typical HTTP Basic prompt with the following description:

  A username and password are being requested by https://ci.mozilla.org. The site says: "/build/ requires a Valid User, see #it if you need it"

This additional level of authentication is silly.

First, Jenkins has its own permissions. You have to be logged in with LDAP credentials to modify anything. At least that's how it should be configured. So, I think the additional HTTP security is not beneficial over what Jenkins already provides.

Second, the URL configuration is trapping extra URLs that don't actually build a project. e.g. if there is a "build" directory in a workspace, the URL ends with "build" and I get prompted to login. That's wrong. If we insist on keeping the HTTP auth, the URL match should be /[^/]+/build not /*/build.

Third, additional protection on the build URL is effectively worthless because there are other mechanisms to trigger builds. For example, the IRC plugin (which many projects have installed) allows users on IRC to send "control" messages to Jenkins. e.g. "jenkins: build project-foo." Upon receipt, Jenkins starts building, bypassing the additional HTTP auth.

I believe I have shown that the presently configured HTTP authentication for URLs with "build" in them is silly and should be removed.

Comment 1

[Jason Crowe [:jd]]

Well as it is now you do not need to be logged in via LDAP to trigger a build. This is a legacy configuration but basically means that anonymous folks can trigger a build. This was likely to enable non corp folks to be able to trigger builds (AKA community members). Given this it would not be possible to remove the auth without first ensuring that every user on every project has some sort of LDAP login so we could remove the anonymous builds.

also FYI they only match for /job/.*/build..... which could still be improved on.

just my 2¢

Comment 2

[Gregory Szorc [:gps]]

Jenkins has very fine-grained permissions management. I just went into the settings and took away the "build" permission from "anonymous" users. If you go to a project's page (e.g. https://ci.mozilla.org/job/mozilla-central-docs/) when you aren't logged in, you will see that the "build now" link is gone. It appears again if you log in.

Since Jenkins auths with LDAP credentials and Jenkins is now enforcing login required for performing builds through the web UI, I'm quite confident the HTTP auth rule is now completely unnecessary.

Comment 3

[Brandon Burton [:solarce]]

(In reply to Gregory Szorc [:gps] from comment #2)
> Jenkins has very fine-grained permissions management. I just went into the
> settings and took away the "build" permission from "anonymous" users. If you
> go to a project's page (e.g.
> https://ci.mozilla.org/job/mozilla-central-docs/) when you aren't logged in,
> you will see that the "build now" link is gone. It appears again if you log
> in.
> 
> Since Jenkins auths with LDAP credentials and Jenkins is now enforcing login
> required for performing builds through the web UI, I'm quite confident the
> HTTP auth rule is now completely unnecessary.

This change broke the jenkins IRC bot, I've reverted it for now and we can evaluate fine tuning the Apache config so it doesn't cover URLs that it is not intended to. Please don't make Jenkins level configuration changes without consulting IT first

Comment 4

[Gregory Szorc [:gps]]

I see I no longer have access to "manage Jenkins" in the Jenkins web UI. Whoever finally locked it down so that any LDAP user can't make changes, thank you. This open access was dangerous for service stability and persisted for way too long.

FWIW, I'm pretty sure you can configure the Jenkins IRC bot to run with permissions of a certain user. Just give that user build privs and all should be OK.

Comment 5

[Brandon Burton [:solarce]]

(In reply to Gregory Szorc [:gps] from comment #4)
> I see I no longer have access to "manage Jenkins" in the Jenkins web UI.
> Whoever finally locked it down so that any LDAP user can't make changes,
> thank you. This open access was dangerous for service stability and
> persisted for way too long.
> 
> FWIW, I'm pretty sure you can configure the Jenkins IRC bot to run with
> permissions of a certain user. Just give that user build privs and all
> should be OK.

This was originally implemented because Jenkins was meant to be mostly self service this level of permissions let users install and manage plugins by themselves and because webops was 2 people at the time, now we are 12.

We working towards a more controlled and manage ci.mozilla.org in combination with a self-service Jenkins service in Labs that let's people get their own Jenkins master that they can customize themselves and manage in isolation, as a way to provide a range of CI services that our users need.

There are a couple more configuration changes I need to review but I expect to be able to remove the build auth by the end of tomorrow

Thank you for your input and feedback in all this, it really is appreciated

Comment 6

[Gregory Szorc [:gps]]

This bug is biting me again.

https://ci.mozilla.org/job/mozilla-central-docs/Tree_Documentation/index.html works.
https://ci.mozilla.org/job/mozilla-central-docs/Tree_Documentation/build/index.html is prompting for credentials.

Can someone please fix the URL match to be less greedy or just remove it completely?

Comment 7

[Brandon Burton [:solarce]]

Finally fixed