1027316 - Enable role-based authentication on Jenkins instances

Status: RESOLVED FIXED

(Testing Graveyard :: WebQA, defect)

Description

[raymond [:retornam] (inactive)]

We have decided to switch from LDAP authentication to role based authentication using the local jenkins user database. This bug tracks work to get this done.



[1]https://wiki.jenkins-ci.org/display/JENKINS/Role+Strategy+Plugin

Comment 1

[raymond [:retornam] (inactive)]

Dave please provide more information on the roles we need to have.

Comment 2

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

Attachment: Screen Shot 2014-06-19 at 17.06.40.png

What I did for Eideticker CI is:
1. Enabled security
2. Disabled remember me
3. Used Jenkins own user database
4. Allowed users to sign up
5. Used role-based authorization strategy (after installing the plugin mentioned in comment 0)
6. Prevented cross site request forgery exploits (using default crumb issuer)
7. Created a role name 'admin'
8. Signed myself up and added myself to the 'admin' role
9. Granted 'admin' all privileges
10. Removed all privileges from 'anonymous' role except overall>read, job>read, and view>read

You don't need to do exactly the same, and you might want a role between anonymous and admin. I've added a screenshot of the global security configuration for Eideticker CI.

Comment 3

[raymond [:retornam] (inactive)]

I have enabled two roles:

admin: can access everything
normal: can read/ view jobs only


Anyone who signs up is assigned the normal role by default. Right now  Dylan and I are the only admins. Please let me or dylan know your usernames after you sign up so we can make you admins.

Comment 4

[raymond [:retornam] (inactive)]

This is now enabled on http://selenium.qa.mtv2.mozilla.com and http://jenkins1.qa.scl3.mozilla.com  Please re-open this bug if you have issues.

Comment 5

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

I'm unable to run any jobs, neither through the Jenkins UI itself (since I'm not an Admin) nor via qatestbot on IRC -- Raymond, can we get a role in-between anon and Admin, which can run jobs?

Comment 6

[raymond [:retornam] (inactive)]

(In reply to Stephen Donner [:stephend] from comment #5)
> I'm unable to run any jobs, neither through the Jenkins UI itself (since I'm
> not an Admin) nor via qatestbot on IRC -- Raymond, can we get a role
> in-between anon and Admin, which can run jobs?

To track admin access grants, please file a bug under https://bugzilla.mozilla.org/enter_bug.cgi?product=Testing&component=WebQA and cc me. 

Do you want the new role on all instances of Jenkins or just one?

Comment 7

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

I think we should allow anonymous users to be able to build at least via invoking the job/build name, on IRC, by triggering it like so (like we had before):

qatestbot: build amo.prod.saucelabs

If we (and by extension me, then) have that, then I'm happy for now; thanks!

Comment 8

[raymond [:retornam] (inactive)]

I've enabled build access for anonymous users so the bot can kick off builds. Please let me know if you have any issues.

Comment 9

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

(In reply to raymond [:retornam] (needinfo? me) from comment #8)
> I've enabled build access for anonymous users so the bot can kick off
> builds. Please let me know if you have any issues.

Appreciate this, Raymond; thank you!

Comment 10

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

(In reply to raymond [:retornam] (needinfo? me) from comment #8)
> I've enabled build access for anonymous users so the bot can kick off
> builds. Please let me know if you have any issues.

I think anonymous build access is a bad idea. We can just allow the qatestbot user this permission. For now, we can restrict build access to authenticated users, so we never see the 'started by anonymous' which is not helpful. In the future we might want a role between authenticated and admin so we can explicitly grant such permissions.

Comment 11

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

Okay, so I've added the qatestbot user and replaced 'normal' with 'anonymous' and 'authenticated' roles. Anonymous users have read access, authenticated users have some elevated privileged such as starting/stopping/updating builds.

I also added myself and other Web QA team members to the list of admins.

Comment 12

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

I've raised bug 1028093 so I can do the same in the new Jenkins instance. I wasn't able to modify config.xml to grant myself admin access due to the files being owned by the jenkins user.

Comment 13

[raymond [:retornam] (inactive)]

> Okay, so I've added the qatestbot user and replaced 'normal' with
> 'anonymous' and 'authenticated' roles. Anonymous users have read access,
> authenticated users have some elevated privileged such as
> starting/stopping/updating builds.
> 
> I also added myself and other Web QA team members to the list of admins.

There are other users who are not registered who kick of builds using the bot. Will this change prevent them from doing so without registering on Jenkins first?

Comment 14

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

(In reply to raymond [:retornam] (needinfo? me) from comment #13)
> > Okay, so I've added the qatestbot user and replaced 'normal' with
> > 'anonymous' and 'authenticated' roles. Anonymous users have read access,
> > authenticated users have some elevated privileged such as
> > starting/stopping/updating builds.
> > 
> > I also added myself and other Web QA team members to the list of admins.
> 
> There are other users who are not registered who kick of builds using the
> bot. Will this change prevent them from doing so without registering on
> Jenkins first?

Yes, they will need to register. This costs them nothing and gives us clear indication of who is kicking off builds. They can always use the IRC bot if they want to avoid registering for some reason, which will then log their nick.