2FA Deployments
Introduction
As a company working in a highly regulated space, it’s important that we have strong controls in place. These controls cover all aspects of our business, ranging from:
- (on the customer service side) ensuring a customer is real and that they get their money from legal sources
to
- (on the engineering side) deploying code into production with checks and balances
This article will explain how we deal with this particular engineering problem.
Approach
There are a number of tools for automating build and deployments. Our tool of choice is Jenkins because it is tried, tested and extensible. Jenkins pipelines make it very easy to automate the build and deployment process through code. In addition, the richness of the Jenkins ecosystem means there are lots of plugins to configure security in precisely the way we need.
To keep our deploy process secure, we need to tweak a few areas of configuration:
- Jenkins authorisation
- Jenkins build job
- Pipeline script (used by the Build Job)
Securing Jenkins
Jenkins is highly configurable when it comes to authenticating (who can log in) and authorisation (what logged in people can do). In this case, we’re concerned with authorisation and to configure that, we used the Role Strategy Plugin. As you can probably guess from its name, the plugin allows you to create roles and assign users to those roles:
The permissions are quite granular. In this case, senior engineers should be able to:
- Overall, Read
- Job, Read
- Job, Build
- View, Read
That means they can login and click the button to deploy.
Securing Jenkins Job
We use roughly the same Jenkins job templates across our environments. In our UAT environments, our engineers can deploy whatever branches they want:
In production, master is deployed and so deploying is essentially clicking a button with a dropdown to choose an approver (which we’ll explain next):
Securing Pipeline Script
When an engineer triggers a build, we go through a fairly standard build process in our UAT environments:
In production we introduce a few extra steps:
The additional steps are magically (using if statements) added in production:
This code should hopefully be clear, it adds two steps to the deployment process:
- ensures the user deploying is asking a different user for permission
- ask that different user for permission via a Duo push notification.
If you don’t know about Duo, it’s definitely worth reading up on. In this instance, we’re using it as 2FA as a service (2FAAAS — an acronym I’ve just made up).
The script referenced in the Jenkinsfile uses a basic python script to construct the request. If the request is approved, then it exits cleanly and the build continues. If not, the script throws an exception and the build fails
The result is when a deployment starts, the approver gets a push notification and the notification must be accepted for the code to be deployed:
Conclusion
That’s it! Deployments into production with a nice convenient approval process.
We are constantly on the lookout for great tech talent to join our team — visit our website to learn more and feel free to reach out to us!
