Welcome to the DevOps Library, this is Samantha, and 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!
Alright, let's begin by talking about the three "A's" of security: authentication, authorization, and auditing.
In this lesson we're going to focus mainly on configuring authentication and authorization.
Let'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.
For 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" dropdown 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 "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".
Before we keep going, let's cover some new terminology.
Well 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 ok, our QA User isn't authorized to do anything yet. Let's switch back to the admin account.
Ok, 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 error. Go ahead and head back to the main Jenkins Dashboard, that way we can create a safe place for our QA team.
Thankfully, the RBAC plugin combines easily with the "Folders" plugin, so we'll create a "QA" folder which we'll then give full access to the QA team to use. After creating the folder, select it, then go to "Groups" on the left side of the page. Next, click "New Quick Group", name it QA Team, and choose "administrator" for the role, then click "Ok.". On the next page, click "Add user/group". Remember that external group we just added in Active Directory? Let's go ahead and type it in here, that way our local Jenkins Group knows which group of users in AD to provide access to, then hit Ok.
Perfect! Log back in as QAUser01 and check it out. Great job!!! We were able to successfully set up a new external group in Active Directory, a new local group on Jenkins, and our QA team is now able to do whatever they'd like without being able to mess up any other team's jobs in Jenkins.
That’s it for our lesson on Jenkins Security, thank you for watching! We’d like to give another shout out to Hired for sponsoring this course. If you’re into DevOps, there’s a pretty good chance you’ve had to deal with pushy recruiters and countless emails, as well as spent many hours searching for DevOps opportunities.
The reason we love using Hired is that it completely reverses this situation and puts the power back in your hands, by having companies send you interview requests that you can choose to pursue. (They even come with upfront salary and equity!)
By having you fill out information that is specific to what you’re looking for and your individual strengths and talents, it ensures that the only companies you’ll hear from will be a great fit for you. Plus, Hired is entirely free, and they’ll even give you a $2,000 bonus after you land a job, using our DevOps Library link!
We highly recommend giving them a shot, they do a fantastic job, especially for the DevOps community.
If you like our videos, please subscribe to our Youtube channel! If you love them and want to help support us, visit patreon.com/devopslibrary, we’ll even list you on our high scores at the end of each video. Thanks again, we'll see you again soon!