Securing Jenkins

This section is a work in progress. Want to help? Check out the jenkinsci-docs mailing list. For other ways to contribute to the Jenkins project, see this page about participating and contributing.

In the default configuration of Jenkins 1.x, Jenkins does not perform any security checks. This means the ability of Jenkins to launch processes and access local files are available to anyone who can access Jenkins web UI and some more.

Securing Jenkins has two aspects to it.

  • Access control, which ensures users are authenticated when accessing Jenkins and their activities are authorized.

  • Protecting Jenkins against external threats

Access Control

You should lock down the access to Jenkins UI so that users are authenticated and appropriate set of permissions are given to them. This setting is controlled mainly by two axes:

  • Security Realm, which determines users and their passwords, as well as what groups the users belong to.

  • Authorization Strategy, which determines who has access to what.

These two axes are orthogonal, and need to be individually configured. For example, you might choose to use external LDAP or Active Directory as the security realm, and you might choose "everyone full access once logged in" mode for authorization strategy. Or you might choose to let Jenkins run its own user database, and perform access control based on the permission/user matrix.

In addition to access control of users, access control for builds limits what builds can do, once started.

Protect users of Jenkins from other threats

There are additional security subsystems in Jenkins that protect Jenkins and users of Jenkins from indirect attacks.

The following topics discuss features that are off by default. We recommend you read them first and act on them immediately.

The following topics discuss other security features that are on by default. You’ll only need to look at them when they are causing problems.

Disabling Security

One may accidentally set up a security realm / authorization in such a way that you may no longer be able to reconfigure Jenkins.

When this happens, the steps to deactivate the Authorization realm depend on the way you manage your configuration.

After following the next sections, when Jenkins comes back, it will be in an unsecured mode where everyone gets full access to the system.

Using JCasc

Locate your configuration as code file, default is $JENKINS_HOME/jenkins.yaml but it can be located in a number of places. Review the Jenkins Configuration as Code plugin for details.

Once you have located the file:

  1. Modify the authorizationStrategy section, so that it configures an unsecured realm:

    jenkins:
      authorizationStrategy: unsecured
  2. Restart your Jenkins instance.

Using a Groovy Script

If you are using a Groovy Script or a Groovy Init Hook to configure your authorization strategy, you should locate the script setting is up. There are multiple ways where it could be set, but essentially you should find a line like Jenkins.instance.authorizationStrategy = myStrategy or setAuthorizationStrategy(myStrategy).

Once you have located the configuration:

  • Comment out the line setting up the strategy.

  • Restart your instance.

Using config.xml (ie you manage your controller configuration in the UI)

  1. Stop Jenkins (the easiest way to do this is to stop the servlet container.)

  2. Go to $JENKINS_HOME in the file system and find config.xml file.

  3. Open this file in the editor.

  4. Look for the <useSecurity>true</useSecurity> element in this file.

  5. Replace true with false

  6. Start Jenkins

If this is still not working, trying renaming or deleting config.xml.



Was this page helpful?

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.