Jenkins access control is split into two parts:
Authentication (users prove who they are) is done using a security realm. The security realm determines user identity and group memberships.
Authorization (users are permitted to do something) is done by an authorization strategy. This controls whether a user (directly or through group memberships) has a permission.
These can be independent, or work in combination. An independent configuration would be Active Directory or LDAP as security realm, and something like Matrix Authorization Strategy as authorization strategy. An example for related security realm and authorization strategy configuration is GitHub Authentication: While its security realm can be used with a generic authorization strategy, it also provides an authorization strategy that looks up a user’s repository permissions on GitHub, and grants or denies permissions to related jobs in Jenkins based on that.
|
Jenkins could be set up to have basic access control happen outside of it. Some examples:
An advantage of these approaches is that they do not allow any access to Jenkins unless a user is authorized, reducing the impact of security issues in Jenkins or plugins especially when accessible from the internet. A disadvantage is the lack of integration with Jenkins access controls and potentially even interfering with it (e.g. when trying to authenticate scripted clients). |
When configuring authentication and authorization in Jenkins, it is easy to accidentally allow far more access than intended. See the documentation on the access given to administrators about the impact of unintentionally granting Administer permission.
The anyone can do anything authorization strategy is very rarely a good choice, as it allows even anonymous users to administer Jenkins. As a rule of thumb, it should not be used. Never rely on the Jenkins URL to not be known outside your team or organization alone for security.
Using the logged-in users can do anything authorization strategy can be a sensible choice as long as only fully trusted users have accounts to access Jenkins. This is the default with Jenkins’s single admin user when setting up Jenkins with the setup wizard.
Switching to an authentication realm that allows untrusted users to have an account later will result in those users getting administrative access to Jenkins if you keep this authorization strategy. Examples include enabling account signup for Jenkins' own user database, or various other authorization realms, many of which (GitHub, Google, GitLab, etc.) allow anyone to sign up for an account.
Similar to the previous items, you should generally not grant significant permissions to anonymous (the anonymous user) or authenticated (any authenticated user) when using an authorization strategy that allows finer-grained control (like Matrix Authorization Strategy).
Granting Overall/Administer permission to anonymous is similar to Anyone can do anything, while granting that permission to authenticated is essentially the same as Logged-in users can do anything.
Users with limited permissions must not be able to configure jobs that run on the built-in node. When setting up a new Jenkins instance, adding users and switching authorization strategies, it is important to also set up distributed builds and limit what jobs are able to run on the built-in node.
At a very basic level, the Overall/Read permission provides users some basic access to Jenkins. This permission is a prerequisite for more substantial access to Jenkins. Without this permission, only very few features explicitly intended to be used without authentication are available.
The highest level of permissions is Overall/Administer. With this permission, users can upload and install plugins and have access to the Script Console.
Between these two extremes is finer-grained permission control involving other permissions. Permissions in Jenkins have a scope: They can be granted globally, on an item (like a folder or job), on a build, etc. Whenever a user attempts to do something that is protected by permissions, the authorization strategy is checked for whether the current user has the specific permission (e.g., Job/Read) on the specific object (e.g., a job). Exactly how permissions are assigned and whether and how they’re inherited is controlled by the specific authorization strategy.
As an example, Matrix Authorization Strategy provides two different authorization strategies:
One provides a single global configuration of all permissions. A user granted Item/Read will be granted that permission everywhere.
One provides a project-based configuration. In this model, permissions can be granted globally (as in the previous strategy), or only on specific folders, jobs, or agents. Permissions are by default inherited, but that can be customized as well, so that users granted Item/Read globally or on a parent folder may be excluded from access to a job.
For more details about the various permissions in Jenkins and the level of access they grant, see Permissions.
Please submit your feedback about this page through this quick form.
Alternatively, if you don't wish to complete the quick form, you can simply indicate if you found this page helpful?
See existing feedback here.