Background
In this tutorial, we will see how we can deploy the Datawiza Access Proxy 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
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 Proxy to the the latest configuration options from the Management Console.
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.
1.4. Create an Application
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 Proxy 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
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 Proxy.
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:
We still need to set a few configuration options on Jenkins to delegate the authentication process to the Access Proxy. We’ll utilize the DAB’s ability to pass user header-attributes to our applications.
3. Passing Header Attributes and Setting up Jenkins Plugins
- 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.
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:
After installing the plugin, go to the Manage Jenkins page and click Configure Global Security.
In Authentication, select HTTP Header by reverse proxy:
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:
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.
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 Proxy also allows us to use https connections for our applications. We can configure this setting by visiting the DCMC.
- Change http in Public Domainto https.
2. Toggle the SSL option and chose to use either Self-Signed certificates or Upload your own.
3. Make sure to also change your Jenkins URL, since we are now using https:
Access Control
- 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:
We set the Default Action to Deny.
We add a rule — only allow members in the group jenkins_manage to have access to our resource.
Now, people who don’t belong to our specified group will be denied when they try to access our /manage resource.
2. Use the existing Jenkins access-control with the Datawiza Access Proxy
Jenkins also has its own Authorization configuration options. With the Access Proxy 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.
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.
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.
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!
- Specify Not Protected for our Rule Type and the Prefix for our Resource Path.
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).
