Securing Jenkins

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

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.

Quick and Simple Security --- if you are running Jenkins like java -jar jenkins.war and only need a very simple setup
Standard Security Setup --- discusses the most common setup of letting Jenkins run its own user database and do finer-grained access control
Apache frontend for security --- run Jenkins behind Apache and perform access control in Apache instead of Jenkins
Authenticating scripted clients --- if you need to programmatically access security-enabled Jenkins web UI, use BASIC auth
Matrix-based security|Matrix-based security --- Granting and denying finer-grained permissions

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