Ldap security for Jenkins CI

I recently deployed Jenkins CI on my personal server. The hardest question was what security solution should I use. As title of this post may have suggested I have chosen to use the infrastructure I already have ... LDAP. Now I would like to describe, how easy this configuration is and how it works.

My LDAP structure

My base dn is dc=effy,dc=cz. And it contains two organizationUnits ... ou=people (to hold users) and ou=groups (to hold user roles). Groups (Roles) are presented by objectClass groupOfNames, they are identified by cn. People (Users) are of objectClass inetOrgPerson, thus identified by uid.


Configuration of Jenkins

Security settings are located in Administration (/manage) -> Configuration (/configure).
The first step is enabling security settings ... that is done by checking check-box Enable security.
The second step is choosing Access Control ... in my case LDAP.
This configuration is pretty simple as long as you have the expected LDAP structure, it could be quite difficult otherwise. You can note that I had to only think about server address and root DN because other values are standards and I am using anonymous LDAP access.
The third step is configuring authorisation rules. The first option (Anyone can do anything) is probably not what you want, because than there would be no need for the LDAP in the first place. I have chosen Matrix-based security, mostly just out of curiosity as I am going to be the only user in medium-term plan.

The only trick here is, that you need to add the groups controlled yourself. Self discovery would be nice, but that is just my opinion.

Testing

Before you finally take Anonymous group the privileges to administer the Jenkins, I would recommend one test login, just to be sure. And you can easily test, what rolles are assigned to your account by visiting the /whoAmI page. This page looks like this:
An interesting and documented feature is that user is assigned two roles per LDAP role. One in upper-case with ROLE_ prefix and one named exactly as in LDAP.

Conclusion

Jenkins offers various security settings which are quite simple to use. This post describes how LDAP connection works and what are its options. I recommend always to use some sort of access control for Jenkins, even if you are going to use Logged-in users can do anything option, just to control the access to Jenkins.

Comments

  1. Hello Peter
    I ahve also integrated the LDAP setting for my Jenkins & it is not throwing any error for the fields for LDAP.

    Now the issue is that i am not able to enter using my LDAP cedentials in Jenkins. Any help please???

    ReplyDelete
    Replies
    1. Greetings Aditya,
      unfortunately there is next to none validation of LDAP settings in Jenkins, the only validated field is Server url.
      It it hard to tell where is the problem without further description.
      From my point of view, the tricky point are:
      Root DN and User search base are the most important fields, verify them,
      try Logged-in users can do anything option to verify if problem is not related to groups,
      verify, that your LDAP has Anonymous access enabled, or try filling the Manager DN a his password.
      And in any case, I would recommend checking the log of the Jenkins (consult a documentation for your system for its location) after unsuccessful login attempt.

      Delete
  2. 你的文章对我帮助太大了 感谢!3ks

    ReplyDelete
  3. Hello Petr,

    I am new to LDAP and all I need is to set up LDAP working with Jenkins.
    Your guide seems to be pretty nice. Though I can't figure out how to define member attribute in groupOfNames object. And what types of objects are used further in groupofnames to create other groups. And in people as well.

    Could you please clarify it a bit?

    Regards,
    Taras.

    ReplyDelete
    Replies
    1. Hello Taras,

      I can certainly try. My example LDAP structure shows only the most basic objects. There are two "folders" of class organizationUnit to keep data organized. One represents Roles (ou=groups), the other Users (ou=people). Those names are completely arbitrary.
      Objects of the class groupOfNames represents the actual Roles (Developers,Testers), these are not only a labels for privileges we want to assign, but they also contains information about their members.
      Objects in ou=people are object of the class inetOrgPerson and they represent users and the most important info they contain is uid, name and password.

      Adding member attribute to the groupOfNames should be straightforward, but it very much depends on what tool you use to create your LDAP structure. This post might help you http://krams915.blogspot.cz/2011/01/ldap-apache-directory-studio-basic.html.

      Hope this helps.

      Best wishes,
      Petr

      Delete
  4. With the developing difficulties confronted by various parts from differing corners and components as of late, security check operations have expected more noteworthy significance relying on the way of exercises completed and extent of asset activation. Indeed, even as there are huge scale security risk discernments on account of open life and property, it has turned out to be practically difficult to give any idiot proof security cover in every single case. https://www.quora.com/How-do-you-check-your-own-criminal-record

    ReplyDelete

Post a Comment

Popular posts from this blog

Automatic jsp recompile on Jboss AS 7

Wicket CDI integration on Jboss AS 7