Securing Access to Jenkins

I think the best approach towards cybersecurity is to be aware of your attack surface and control your exposure to potential risks.

Jenkins is a popular and versatile tool, it is the gut of the CI/CD pipeline for many organizations. Here in Appaegis, we also use Jenkins to drive our CI/CD process. Securing the CI/CD environment is at the center of protecting an organization’s digital assets, but in many cases, it is also a complex task. In the case of Jenkins, we need to secure the credentials it needs to use, secure the code and artifacts stored in it, assign proper user access roles, and provide a secure runtime environment.

One of the first things Jenkins admin needs to do is securing access to its user interface. If you deploy Jenkins in the cloud, like we do, there are a few things you need to consider:

• Never ever allow open access from the Internet, not even if you use a clever custom port number. Your Jenkins server is a high-value target, guard it as if your life depends on it.
• Consider external user account authentication to get more security features. The default authentication module lacks features such as password complexity policy and 2FA/MFA.

When we come up with the idea of Appaegis Access Cloud (AAC) one year ago, providing secure access to internal applications is one of the main goals for our enterprise customers. Now our new production system is online, it is time to use AAC to protect our DevOps infrastructure. Nearly everyone in the team uses Jenkins, so it is the first on our list.

We have been manually maintaining the AWS security group to control access to our infrastructure running on AWS. That approach works for our small team, but there are obvious problems:

• We can allow all of our engineers to modify the security group setting for the development environment, but that will not be the case for our production system.
• We use multiple AWS regions, there are a few places we have to change.
• There is no good way to clean up these IP whitelists. We did it once by removing IP’s in question and asking everyone to check if they were affected.

This is what we’ve been doing

Now we can solve these problems with our own product. Below is a quick recount of the setup steps.

• First register and login to Appaegis Access Cloud as admin of your organization (You can request a demo).
• Create a “network” object, download the docker-compose configuration file for running the connector (Service Edge).
• Start the Service Edge (SE) container by running that docker-compose file. However in our case, we are running the SE container within our EKS cluster, so we wrote a deployment YAML file. The benefit of doing that is we can access services running “inside” EKS with their “cluster IP” directly, without the need to bind external IPs or load balancers to them.

The original docker-compose file and the deployment file for our EKS

• The original docker-compose file and the deployment file for our EKS
• Check the status of the network to make sure it shows “online”
• Add the Jenkins application, by using its “cluster IP”
• Invite other engineers as user
• Refine access management by organizing users into teams

This is how we access our Jenkins now

Let’s review on how Appaegis Access Cloud is securing access to Jenkins:

• Take the direct access to Jenkins UI off the Internet completely.
• We can enforce password policy at the AAC portal login level, which also comes with advanced features such as 2FA/MFA and SSO.
• We can also use our “Isolated Password Vaulting” feature to bind the Jenkins’ account with the AAC portal login.