The default configuration of Jenkins in earlier versions does not contain security check. Anyone can enter Jenkins anonymously and perform a build operation. However, security control is important for most Jenkins applications, especially those exposed on the Internet. Many security-related options are enabled in the default configuration of Jenkins 2.0 and later versions to guarantee the security of Jenkins environments, unless the administrator intentionally disables some protection options.
This article describes various security-related options that the Jenkins administrator can use to harden your Jenkins service and prevent hacking.
Jenkins access control includes Security Realm (authentication) and Authorization Strategy.
The security realm determines users and their passwords, and what groups the users belong to. The default options include Jenkins’ own user database, LDAP, and Servlet container agents.
The authorization strategy determine who has access to what. The default options include: Anyone can do anything (without restriction), matrix-based security, logged-on users can do anything, legacy mode, and project-based matrix authorization strategy.
Regularly check official Jenkins security bulletins and update Jenkins to the latest official version to prevent deployment of versions with security vulnerabilities.
In Jenkins 2.0 and later versions, the Enable security check box is selected by default. The Jenkins administrator can enable, configure, or disable key security functions that apply to the entire Jenkins environment in the Enabled security area of the Web UI.
By default, anonymous users do not have any permission, while logged-on users have full control. You can log on to Jenkins with a user name and password to perform operations that are unavailable to anonymous users. You can also select and configure the authorization strategy to determine operations that can be performed only after user logon. You must always enable this check box in any non-local Jenkins environment.
Jenkins uses the TCP port to communicate with agents that are enabled through JNLP, such as a Windows-based agent. This port is disabled by default in Jenkins 2.0 and later versions.
For administrators who want to use a JNLP-based agent, the following types of ports are available:
Random: A JNLP port is randomly selected to avoid conflicts with the Jenkins host. If this type is used, it is difficult to manage the firewall rules that allow JNLP traffic during the boot of the Jenkins master.
Fixed: The Jenkins administrator selects the JNLP port, which is the same as that when the Jenkins master restarts. If this type is used, it is easier to manage the firewall rules, and JNLP-based agents can be connected to the master server.
Access control is the main measure to protect the Jenkins environment from unauthorized use. Access control configured in Jenkins involves the following aspects:
Console. Typically, an administrator does not manage Jenkins on the Internet. Instead, the administrator restricts the access permissions for source IP addresses and ports based on business requirements to prevent malicious users from accessing the backend.
Security Realm. It notifies the Jenkins environment how and where the user or tag information can be obtained. It is also known as “authentication.”
Authorization. It notifies the Jenkins environment which data is accessible to a user or group.
With the security realm and authorization configured, you can easily configure rigid authentication and authorization schemes in Jenkins. You can also use some plug-ins, such as role-based authorization strategies, to extend the access control capabilities to support more precise authentication and authorization schemes.
The security realm or authentication specifies the users who are permitted to access Jenkins, while authorization specifies the data that the users are permitted to access in Jenkins.
Jenkins supports the following authorization options by default:
Anyone can do anything. Jenkins can be fully controlled by anyone, including anonymous users who have not logged on to the system. Apply this setting only to a local test of Jenkins management.
Legacy mode. The admin users have full control on the system. Other users, including anonymous users, only have the read permission. Apply this setting only to a local test of Jenkins management.
Logged-on users can do anything. Every user who is currently logged on can fully control Jenkins. You can also decide whether to allow or reject anonymous users to read data from Jenkins. This mode forces users to log on before performing any operation, making audit trail of user operations possible.
Matrix-based security. The operations that users and groups are permitted to perform in Jenkins can be precisely controlled.
Project-based matrix authorization strategy. This authorization strategy is the extension of matrix-based security. After this strategy is applied, an additional access control list (ACL) can be defined separately for each project on the project configuration interface. It allows a specific user or group to access the specified project, rather than all projects in the Jenkins environment. The ACL defined using the project-based matrix authorization strategy is added so that the access permission defined on the Configure Global Security interface is combined with the project-specific ACL.
Each row in the preceding figure indicates a user or a group (also known as “role”). This includes special items “anonymous” and “authenticated”. The “anonymous” entry indicates the permissions granted to all unauthenticated users accessing the Jenkins environment. “Authenticated” is used to grant permissions to all authenticated users who access the environment.
The permissions granted to the matrixes can be inherited. For example, if the user “kohsuke” is in both the “Developer” and “Administrator” group, the user “kohsuke” can have all permissions granted to itself, “Developer”, “Administrator”, “Authenticated”, and “Anonymous”.
Jenkins provides a series of plug-ins related to authentication and user management. You can install and use them based on your business requirements from https://plugins.jenkins.io/. For example:
Active Directory Plugin: Allows the use of Microsoft Active Directory (account of the Windows domain) for authentication.
Crowd Plugin: Allows the use of Atlassian Crowd for authentication.
Script Security Realm Plugin: Allows the use of custom scripts for authentication.
Role Strategy Plugin: Provides the role-based authentication strategy that supports definition of global and project set roles and assigns the related roles to users.
Cross-site request forgery (CSRF/XSRF) is a vulnerability that allows an unauthorized third party to run a request on a Web application by simulating an authenticated user. In the context of the Jenkins environment, a CSRF attack may allow a malicious actor to delete a project, change the construction, or modify the Jenkins system configuration.
To prevent this vulnerability, CSRF protection is enabled by default in Jenkins 2.0 and all later versions.
After this option is enabled, Jenkins checks the CSRF token or “crumb” on any request that may change data in the Jenkins environment. This includes any form submission and call to remote APIs. Submission of forms that use “basic” authentication is included.
However, CSRF protection may challenge the advanced use of Jenkins. For example:
- Some Jenkins features, such as the remote API, become more difficult to use when this option is enabled.
- If you use a reverse proxy with incorrect configuration to access Jenkins, the CSRF HTTP header may be removed from the request, resulting in a protected operation failure.
- Outdated plug-ins for which CSRF protection test is not implemented may not work properly.
For more information about the CSRF vulnerability, visit the OWASP website.
For more information about how to configure Jenkins security features, see the official documentation of Jenkins.