Protecting Jenkins using the Datawiza Access Broker (Single-Sign-On and Granular Access Control)

January 8, 2021
Rahul Toppur

Background

In this tutorial, we will see how we can deploy the Datawiza Access Broker (DAB) in front of Jenkins. We will also see the features provided by the DAB, such as the ability to pass user header attributes and cookies and implement granular access control.

For this tutorial, Jenkins is currently running in a docker container on port 8080:

http://{your_jenkins_url}:8080

We’ll take a look at deploying the DAB to protect Jenkins.


Deployment

1. Configuration in Datawiza Cloud Management Console (DCMC)

First, we need to visit https://console.datawiza.com. Once we create an account, we can Create a new Deployment.

1.1. Create a New Deployment

Image for post

1.2. Create a New Set of Provisioning Keys

We also need to generate a set of PROVISIONING KEYS. These keys will later be used in our docker-compose file and will allow the Access Broker to the the latest configuration options from the Management Console.

Image for post

1.3. Configure an Identity Provider

Choose your preferred Identity Provider from the drop-down menu. In this example, we are using Okta as our IdP. You will need to populate these fields with an Okta dev-url, client id, and client secret--all of which can be found in the Okta developer console for your application.

Image for post

1.4. Create an Application

Image for post

Set the Upstream Server to http://{your_jenkins_url}:8080. This is the URL where Jenkins is running locally on your machine. Set the Public Domain to the URL where you want the user to externally access your application.

The Default Action option is the default action taken by the Access Broker if no rules are found. Set this option to Allow for now--we can always change this field once we specify some rules later.

1.5. Final Deployment Configuration

Image for post

Make sure to note down the PROVISIONING_KEY and PROVISIONING_SECRET. A sample docker-compose file is provided for you--feel free to use this when launching the DAB.

2. Deploying the DAB

After creating and specifying our deployment options in the DCMC, we can use docker-compose to deploy the Datawiza Access Broker.

We can use docker-compose -f docker-compose-jenkins.yaml up -d to start the service. If we set the resource limit in our docker-compose file, we need to add --compatibility in docker-compose command.

Now, when we visit http://{your_jenkins_url}:8080, we will be redirected to the Okta login page.

If we set the Upstream Server to http://{your_jenkins_url}:8080, the docker-compose file will be:

version: "3" services: access-broker-jenkins: container_name: access-broker-jenkins image: registry.gitlab.com/datawiza/access-broker ports: - "8090:8090" environment: PROVISIONING_KEY: ########################## PROVISIONING_SECRET: ########################## # We can add configuration options here to set the access broker's resources # deploy: # resources: # limits: # cpus: '1' # memory: 512M


We still need to set a few configuration options on Jenkins to delegate the authentication process to the Access Broker. We’ll utilize the DAB’s ability to pass user header-attributes to our applications.

3. Passing Header Attributes and Setting up Jenkins Plugins

  1. Add a new Header-Attribute for both login and groups. The Field name comes from our IdP, and the Expected value is what our legacy application will be expecting to see in our header.
Image for post
Image for post
Image for post
Image for post
Image for post

After making these changes on the DCMC, we need to set up the Reverse Proxy Auth plugin in Jenkins to make sure it is expecting to see the user Header-Attributes we plan to pass along with our request.

2. Add the Reverse Proxy Auth in Jenkins:

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post


After installing the plugin, go to the Manage Jenkins page and click Configure Global Security.

Image for post
Image for post

In Authentication, select HTTP Header by reverse proxy:

Image for post
Image for post

We have already set email and groups as Expected values in the DCMC. So, we need to make sure that the values of the headers match:

  • Header User Name: email
  • Header Groups Name: groups
  • Header Groups Delimiter: “:"

These values should be identical to the ones we specified in the Expected section in the DCMC for our Header-Attributes.

In addition, we can also set the Custom Log Out URL in the Advanced settings:

Image for post
Image for post

It should be set to http://{your_jenkins_url}/ab-logout.

Make sure to save your changes when finished!

Logging in to Jenkins

Now, when we visit our Jenkins URL, we should be prompted to sign in once more with our IdP. Once we have been authenticated, we should see our Okta username in the right-hand corner.

Image for post
Image for post

We can use the logout button which will redirect to the Okta login page as well.

Going Further: Other Supported Features

SSL

The Datawiza Access Broker also allows us to use https connections for our applications. We can configure this setting by visiting the DCMC.

  1. Change http in Public Domainto https.
Image for post
Image for post

2. Toggle the SSL option and chose to use either Self-Signed certificates or Upload your own.

Image for post
Image for post

3. Make sure to also change your Jenkins URL, since we are now using https:

Image for post
Image for post

Access Control

  1. We can specify access control policies to further restrict users who sign in to Jenkins using our IdP. To do so, we need to add a few configuration options in the DCMC.

For example, let’s say that we only want people in the group jenkins_manage to have access to our Jenkins resource. We can set our rules in the DCMC accordingly:

Image for post
Image for post

We set the Default Action to Deny.

Image for post
Image for post

We add a rule — only allow members in the group jenkins_manage to have access to our resource.

Image for post
Image for post

Now, people who don’t belong to our specified group will be denied when they try to access our /manage resource.

Image for post
Image for post

2. Use the existing Jenkins access-control with the Datawiza Access Broker

Jenkins also has its own Authorization configuration options. With the Access Broker and the Reverse Proxy Auth, we can set the Authorization options for people and for groups. For example:

  • For the jenkins_read group, only allow users to view credentials, read jobs, and read views
  • For the jenkins_admin group, allow them to do anything.
Image for post
Image for post
Image for post


Image for post

Once we specify our options, click Save.

If a user is part of the jenkins_admin group, they should see a similar page when they log in. Note that they are able to see the “Manage Jenkins” menu option.

Image for post
Image for post

However, if a member of the jenkins_read group logs in, they will only be able to see the following page. Note that this user cannot access the “Manage Jenkins” menu.

Image for post
Image for post

WebHooks

Configuring webhooks are as simple as creating a new rule on the DCMC. We simply need to specify a new Resource Path and a Rule Type, and we are all set!

  1. Specify Not Protected for our Rule Type and the Prefix for our Resource Path.
Image for post
Image for post

2. If using https for Jenkins, we also need to change the configuration of our webhooks. In this case, we have chosen to use https and have skipped certificated verification (if we are using self-signed certificates).

Image for post
Image for post


DOWNLOAD IN PDF