1121453 - Configure Web QA's Jenkins instance to use LDAP for access control

Status: RESOLVED FIXED

(Infrastructure & Operations :: Infrastructure: LDAP, task)

Description

[Dave Hunt [:davehunt] [he/him] ⌚BST]

We'd like to see if we can get Web QA's Jenkins instance to use LDAP for access control. This is something we've had before, but more recently switched to Jenkins own user database. As we're now wanting to make the Jenkins instance publicly accessible, one suggestion from our security review (bug 1118241) was to revisit using LDAP.

The settings that can be configured are covered here: https://wiki.jenkins-ci.org/display/JENKINS/LDAP+Plugin I suspect the minimum we need is the server details.

If our LDAP doesn't support anonymous binding then we'll need a manager DN and manager password so that Jenkins can query it.

Comment 1

[Dave Hunt [:davehunt] [he/him] ⌚BST]

Stephen: I understand you set up LDAP access previously, possibly with some assistance. Are there any additional details we need?

Comment 2

[Stephen Donner [:stephend] Not actively reading bugmail]

(In reply to Dave Hunt (:davehunt) from comment #1)
> Stephen: I understand you set up LDAP access previously, possibly with some
> assistance. Are there any additional details we need?

Yep; last time, Raymond and I worked with :jabba (see bug 691586).

Comment 3

[Dave Hunt [:davehunt] [he/him] ⌚BST]

Thanks Stephen! Reading that, it sounds like we need the LDAP host to use from SCL3 with ACLs updated to allow webqa-ci1.qa.scl3.mozilla.com to bind to it. I suspect the bind user mentioned is what the plugin refers to as the manager, so we'll either need a new bind user or perhaps we can use bind-qa as created previously? Either way, could we be provided the user/password details.

From bug 691586 comment 1:
> The ldap host to use in the MV office is "ldap://mv-ns.mv.mozilla.com". I've
> updated the ACLs on it to allow qa-selenium.mv.mozilla.com to bind to it.
> 
> I've also created a bind user for this service to use (and other qa
> services). The bind user is "uid=bind-qa,ou=logins,dc=mozilla". Please ping
> me on irc for the password for this account.

Comment 4

[Justin Dow [:jabba]]

The main thing is that we need to make sure that the jenkins instance is only available over SSL, so that users don't ever send their LDAP credentials in the clear. If that is already done, then if you can grant me admin access to the jenkins server, I can configure the LDAP portion for it. We'll also need a plan for how to deal with existing users in the jenkins user database and whether jenkins supports allowing both authentication methods, or if those user accounts will get lost or inaccessible. We can set up a time to do this together, so that we can test and revert as needed throughout the process.

Comment 5

[Dave Hunt [:davehunt] [he/him] ⌚BST]

(In reply to Justin Dow [:jabba] from comment #4)
> The main thing is that we need to make sure that the jenkins instance is
> only available over SSL, so that users don't ever send their LDAP
> credentials in the clear. If that is already done, then if you can grant me
> admin access to the jenkins server, I can configure the LDAP portion for it.
> We'll also need a plan for how to deal with existing users in the jenkins
> user database and whether jenkins supports allowing both authentication
> methods, or if those user accounts will get lost or inaccessible. We can set
> up a time to do this together, so that we can test and revert as needed
> throughout the process.

This is a new Jenkins instance so nothing has really been configured yet. It's currently accessible via http://webqa-ci1.qa.scl3.mozilla.com:8080/ and the bug to open this up is currently blocked on bug 1120384, which mentions HTTPS and certificates (if you know who could work on that, please advise).

I'm the only user in there at the moment, so replacing this with LDAP is not a problem. I have configured an administrator role though so there's a risk if you configure LDAP that I'll be locked out - as you say it's probably best to coordinate this so I can relax the permissions until I can make sure I'm an admin again.

I have also been documenting the basic configuration of this box, so would like to have details of any configuration changes you make.

Comment 6

[Justin Dow [:jabba]]

Excellent, that makes it easy then. Let me know when we can coordinate this over IRC and we can get it sorted pretty quickly. As far as making it publicly accessible, you'll probably want to file a bug in one of the Web Operations components like WebOps: Other within the Infrastructure & Operations product. If the instance is not currently publicly accessible, then we can go ahead and proceed with the LDAP stuff.

Comment 7

[:Atoll]

Reading bug 1120384, the HTTPS and SSL certificates will be handled at the load balancer level by WebOps, forwarding to the non-SSL :8080/tcp on the backend.

:jabba, does that comply with the HTTPS requirement you describe?

Comment 8

[Dave Hunt [:davehunt] [he/him] ⌚BST]

:jabba helped to get this set up, so closing as FIXED. Setting needinfo based on comment 7 though.

Comment 9

[Justin Dow [:jabba]]

(In reply to Richard Soderberg [:atoll] from comment #7)
> Reading bug 1120384, the HTTPS and SSL certificates will be handled at the
> load balancer level by WebOps, forwarding to the non-SSL :8080/tcp on the
> backend.
> 
> :jabba, does that comply with the HTTPS requirement you describe?

Yeah, that's fine with me. Just need to make sure that the public IP either doesn't listen on :80 at all, or automatically redirects all requests to :443 there, so that there is no possibility of a user entering LDAP credentials in the clear across the internet.

Comment 10

[:Atoll]

'doesn't listen on :80 at all' is probably mandatory, and should be the case anyways (along with an HSTS header on :443, just because).