Jenkins Security

In this lesson, we will explore various aspects of securing your Jenkins installation. We cover essential principles including configuring credentials for pipelines, managing global security settings, and safeguarding both the Jenkins server and its source code.

We begin by discussing how to add credentials during pipeline configuration. Jenkins provides a centralized global security settings page where you can define authentication methods, select security realms, configure authorization strategies, and set markup formatters.

Although we reviewed the global configuration settings earlier, this discussion takes a deeper dive into what security means specifically for Jenkins. Unlike services such as GitHub, which typically offer CI/CD as a SaaS, Jenkins is usually hosted on your own server. This self-hosted setup means that securing Jenkins involves protecting your code, controlling access to pipelines, and ensuring that server and system configurations are secure.

A fundamental aspect of Jenkins security is user and access control, which can be divided into two main components:

1. Authentication: Where users prove their identity through a defined security realm that manages user identities and group memberships.
2. Authorization: After authentication, users are granted specific permissions to perform actions. For example, one user might have the ability to edit a pipeline, while another might have restricted access.

Authorization in Jenkins is implemented via an authorization strategy. This strategy determines what permissions a user or group receives, such as the ability to modify a CI/CD pipeline.

Common Jenkins Security Pitfalls

Below are some common mistakes that can significantly compromise the security of your Jenkins installation. Addressing these issues is critical for maintaining a secure CI/CD environment.

1. Anyone Can Do Anything
   Using an open authorization strategy that allows everybody, including anonymous users, to administer Jenkins is highly insecure. Relying on obscurity, such as non-public Jenkins URLs, does not protect your system.

2. Logged-In Users Can Do Anything
   Even authenticated users should have tailored limitations. Similar to how AWS uses IAM to restrict user actions—even when using programmatic access—Jenkins must restrict what logged-in users can do via role-based permissions.

3. Excessive Permissions for Anonymous or All Authenticated Users
   Granting overly broad permissions, even to authenticated or anonymous users, introduces significant risk. Utilize fine-grained controls like the matrix authorization strategy to ensure that no generic account has full administrator privileges. Often, it is best to completely disable or heavily restrict access for the anonymous user.

4. Insecure Use of the Built-in Node
   The built-in node—where Jenkins itself is installed—should not be used for running builds if users have limited permissions. Although examples in CI/CD pipeline tutorials might use the built-in node, industry best practices recommend dedicated build agents for running jobs. This minimizes security risks by preventing unauthorized job execution on the main Jenkins server.

In summary, securing Jenkins involves multiple layers—from safeguarding the server installation and pipelines to enforcing strict user access controls. Addressing these common security issues will help ensure that your Jenkins environment remains robust and minimizes the risk of unauthorized actions.

Let's now dive into hands-on practices. In the following sections, we will walk through various Jenkins security concerns, implement the necessary fixes, and explain the rationale behind each solution.