Welcome to the DevOps Library. In today’s lesson, we’re going to talk about securing Jenkins (including the difference between authentication and authorization ), how to set up different types of security realms , using AD for authentication, and even how to use the Jenkins role-based access plugin!
3 As of Security
Alright, let’s begin by talking about the three AS of security:authentication,authorization, andauditing.
Authenticationis simply the process of proving that someone is who they say they are.
Authorizationis the process of determining what someone is allowed to do after they’ve authenticated.
Auditingis the process of creating a record of everything that happens, along with who did what.
In this lesson, we’re going to focus mainly on configuring authentication and authorization.
Implementing Security in JenkinsLet’s go ahead and see how to implement these concepts within Jenkins. Pull up a Jenkins master, then head to Manage Jenkins , followed by Configure Global Security . Alright, first, we’ll want to enable security, so go ahead and check the box if it isn’t already.
Next, we need to choose a security realm, which is used for the authentication step, so verifying the user, their password, and what group they belong to is all part of it. As most companies use Active Directory, we’ll use that and go ahead and type our Domain Name in. Make sure you’ve set up DNS so that your Jenkins master can resolve the domain, then go ahead and click Test to verify that the connection worked.
Alright, now before we move on, make sure you log into a domain account (or whatever realm you chose), then return back to the global security page.
Next, it’s time to decide on which authorization strategy we’d like to use.
Authorization Strategies Anyone can do anything is pretty self-explanatory. Legacy mode isn’t much more useful, as it only gives you two levels of access: “admin” which has full control, and everyone else (including anonymous users) has read-only. Logged-in users can do anything is only useful if you’d like everyone to have auditable admin access, and probably isn’t very useful outside of smaller teams. Matrix-based security is about the best you can get in the open source edition of Jenkins, as it really lets you get pretty granular on the permissions. Let’s go ahead and take a look at it real quick. See this really long line with all the checkboxes? That’s how we assign permissions to each user. While it is extremely granular, you can’t assign different rights to different jobs. The Project-based Matrix Authorization Strategy is exactly the same, as the normal matrix-based option, but lets you specify different permissions on each job’s configuration page. You can certainly get by for awhile using this option, but it does become pretty cumbersome as there’s no way to manage groups of projects. Lastly, we have the Role-Based Matrix Authorization Strategy , which is unfortunately only available in the enterprise version of Jenkins, but it’s definitely the most flexible and easiest to manage as your team scales. Role-Based Access StrategyFor this lesson, let’s go with role-based , as it can do everything the other models can do and more, and it’s also heavily targeted on the Jenkins certification exams. You’ll notice that when you select it, an Import Strategy drop-down appears. Change it to Typical Initial Setup , then hit Save . If you didn’t see the initial setup dropdown, make sure you’re logged in otherwise it won’t be available. It automatically creates a group of administrators, of which initially you’ll be the only member, as well as a Developers group and a Browsers group. Speaking of groups, check out the menu on the side. We have two new items, one for managing Groups and another for Roles .
New TerminologyBefore we keep going, let’s cover some new terminology.
A local group refers to a set of users, external groups, or even other local groups, and are defined by the Jenkins RBAC plugin that we’re now using. To manage them, click the Groups link on the left. Here you can see our three new groups created by the initial configuration. An external group also refers to a group of users, but one that is defined outside of Jenkins, like an Active Directory Group. A permission is the right to do something, such as starting a job or creating a new project. A role is simply a collection of permissions, which makes them much easier to manage. Let’s check them out real quick. Go to Manage Jenkins , followed by Manage Roles .On the left side of the table, you can see the names of our roles, and on the right, we can assign permissions to each of them. See the little green hat by Anonymous and Authenticated ? That’s because those two roles are built into Jenkins, so you won’t be able to delete them. The rest were all created by the initial setup wizard, so you can do whatever you’d like with them. Lastly, we have role filters , which are used at the job level to prevent roles from being propagated. As an example, let’s take our Browse group, whose members have read access to everything, and create a job that they can’t see. To do so, click the job, go to Roles ,followed by Filter ,and set Require Explicit Assignment on the Browse role. Pretty useful, huh? Real World Use CaseWell, that’s enough new terminology for now. Let’s try out an actual real world use case. Pretend we have a QA team that need to be able to create, configure, and build any job that they’d like. However, we also want to ensure that they’re not able to access anything outside of the jobs that they create for QA purposes. Don’t worry, it’s really easy.
First, hop on the domain controller that Jenkins is using for authentication. Once there, open up Active Directory and add a QA user. We’ll name ours QAUser01 . Next, we need to create a security group. Let’s go with Jenkins-QA . Now add QAUser01 to the Jenkins-QA group, then switch back to Jenkins.
Alright, let’s log out and try logging back in with our QAUser01 account. Oops! While we were able to authenticate, our QA User isn’t authorized to do anything yet. Let’s switch back to the admin account.
Go to Manage Jenkins , followed by Manage Roles . On this page, click the checkbox for Overall Read access for authenticated users, then hit Save . We’re giving that to every logged-in user, as it’s the absolute bare minimum required to successfully open the Jenkins dashboard without an