Jenkins Platform: Risks of Misusing Jenkins for Automations

Jenkins is Good

Let’s start with the obvious. Jenkins is a modern miracle. This venerable DevOps automation server was initially released on February 2, 2011, and few platforms have managed to achieve and maintain such a positive reputation within its community of developers, as well as a creating a vibrant ecosystem of plugins and educational resources. In just over 10 years, Jenkins has become a workhorse in DevOps automation for platform engineering teams big and small.

According to their official website, “Jenkins is the way to build, test, and deploy [cloud applications].” This is a good summary of what Jenkins does well. Primarily, it is “an extensible automation server, [that] can be used as a simple CI server or turned into the continuous delivery hub for any project.”

In other words, Jenkins was built to solve for the continuous delivery and deployment of software. You can use Jenkins to build your code from many different services, run tests on your code, and then ultimately deploy your code to your cloud infrastructure. All these activities must occur before an application is available in production.

But, that’s not all Jenkins is being used for today.

This article is about how many skilled DevOps and SREs currently misuse Jenkins for automations completely unrelated to CI or CD. We’ll explore some of the more common use cases for abusing Jenkins, and identify what are the bigger risks of using Jenkins for CloudOps use cases.

Jenkins is Bad (Sometimes)

There’s a whole different class of operations activities concerned with managing, maintaining, and securing already in-production cloud applications.

These include many activities, such as:

• IT Operations (ITOps)
• Cost & Resource Optimization (FinOps)
• Cloud Security (SecOps)
• Incident Response & Remediation
• Cloud-Native Troubleshooting
• Identity Management
• Observability
• Mobile Device Management
• Compliance

Every single bullet above has an entire category of cloud tools associated with that specific activity. Each of these tools requires some degree of custom integration effort, configuration, and learning its own unique terminology and user experience.

Platform engineers are constantly onboarding, learning, and integrating to new cloud platforms. The widespread adoption of cloud-native and serverless architectures has redefined the daily experience of platform engineering teams. DevOps and SREs now spend much of their time doing CloudOps – building integrations, manually administering cloud platforms, and writing scripts to automate manual processes.

Jenkins may be a perfect fit for DevOps, but it’s not a good match for CloudOps.

Jenkins is Not a Platform

One common misconception about Jenkins is that it is a DevOps automation platform, which isn’t quite true. There’s a very good reason why the Jenkins website says “DevOps automation server” instead of “DevOps automation platform.” That’s because Jenkins does not include many of the usability features commonly associated with platforms.

For example, there is the whole aspect of managing your Jenkins. Unlike managed cloud services like AWS or Slack, Jenkins is a service that you need to manage by yourself. That means you’re on your own for setting up RBAC, access, backups, plugin management, etc…

This a complete headache, and only skilled platform engineers are able to do this kind of work. Most of the industry are consuming managed services because of that pain, but platform engineers ignore this problem with Jenkins because it seems like there are no better options.

Why You Shouldn’t Use Jenkins for CloudOps Automation

Compared with DevOps, VMware explains that “CloudOps codifies procedures and best practices for cloud-based operational processes, much as DevOps codifies the same for application development and delivery processes.”

Until , there wasn’t a general-purpose CloudOps automation platform. Without an optimal solution, resourceful platform engineers turned to their trusty companion Jenkins to orchestrate CloudOps workflows across different cloud services. While you can hack your way to a working automation in such cases, this is actually an anti-pattern that you should steer clear to avoid.

Let’s examine why Jenkins is not a fit for CloudOps.

Consider this self-service workflow. Suppose you want to build a Jenkins pipeline that automatically creates a new customer license on-demand. In Jenkins, this is a problem. Running a self-service automation on Jenkins requires the consumer to have Jenkins access. Since you probably use Jenkins as a CI/CD tool, it already has access to your private networks. Now, that consumer requires access to sensitive networks, just in order to run a simple Jenkins workflow.

That means whenever your business team needs to create a new customer license, they are at risk of jeopardizing your cloud application’s security and reliability.

3 Warning Signs That Your Organization Has Bad Jenkins Hygiene

There are a number of ways to determine if your organization is exhibiting risky behavior using Jenkins.

Here are 3 warning signs that your organization has bad Jenkins hygiene:

• Users who are not developers or DevOps engineers with Jenkins accessGiving users other than developers or DevOps engineers access to Jenkins is always an anti-pattern, and runs completely counter to least privilege methodology. It’s important to note that since Jenkins is responsible for CD, it has permissions and access to all your cloud environments, secrets, and in some use cases, even databases. Here’s a simple rule. Only those who are capable of configuring a CI/CD pipeline should have access to your Jenkins service.
• Automations that are not CI/CD orientedAre a number of your Jenkins automations unrelated to CI or CD? Beware. Just because you can find a plugin that works, or an automation seems convenient, doesn’t mean it’s a good idea. Third-party plugins can introduce unnecessary reliability and security risk. Furthermore, bespoke Jenkins automations often work for the platform engineer who created them, but good luck once that engineer is on PTO or moves to a new job.
• Giving VPN access to peers who only need it to execute an automationIt’s never a good idea to give VPN access unless when absolutely required. While it may seem convenient to share a Jenkins automation, you’re creating unnecessary security exposure for your network. It could even be worse, some organizations wind up exposing Jenkins workflows on the internet, making them accessible by anyone. Yikes!

If you identify any of these anti-patterns, there’s a better option for your CloudOps automation workflows than using Jenkins.

Blink is a Better Choice for CloudOps Automation

Blink is a no-code/low-code automation platform that’s purpose-built for CloudOps. Blink comes loaded with more than 20,000 cloud-native actions and an Automation Library of over 300 automation templates for common CloudOps workflows.

Blink makes it simple to compose, manage, and secure all your cloud and security operations workflows. You benefit from a fully-featured cloud platform, with managed workspaces for all your different teams and projects. Blink workspaces come with support for granular RBAC and self-managed Git repositories. Bring all your existing scripts and processes, or quickly compose new no-code/low-code automations.

Enable development and business teams with a self-service portal

Blink also redefines how DevOps and SREs serve the other teams within their organization. Using Blink, CloudOps teams can provide a self-service portal with on-demand automations to developers, business stakeholders, and executive leadership. This proactive service model significantly reduces context-switching associated with ad hoc service requests. Furthermore, CloudOps teams can expose on-demand automations via Slack, Teams, or project management platforms to engage stakeholders wherever is most convenient.

Get Blink Early Access

Blink helps DevOps, SecOps, and SREs achieve flow in their everyday work, by making it easy to create automated workflows across the cloud platforms and services they use every day. The impact of adopting a low-code/no-code platform like Blink is happier, more productive teams and more reliable, resilient, auditable cloud operations.

The best part? Blink early access is available today. Try out the future of no-code/low-code CloudOps for yourself. Get started with Blink today.