|
In the default configuration, Jenkins does not perform any security check. This means any person accessing the website can configure Jenkins and jobs, and perform builds. While this configuration is acceptable during initial evaluation of the software, Jenkins should be configured to authenticate users and enforce access control in most other situations, especially when exposed to the Internet. This setting is controlled mainly by two axes:
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. Topics
CSRFIndependently of authentication and authorization, you generally should enable to option to use “crumbs” to defend Jenkins against CSRF attacks. Markup formattingAgain independently, you can select what kind of rich-text markup is permitted in things like job descriptions. The default formatter allows a restricted subset of HTML. You can choose others, typically based on wiki syntaxes. Security ImplicationNote that even when security is enabled, builds that are run on the “master computer” can read, or modify, files in $JENKINS_HOME. Since only Jenkins administrators should have that authority, you should generally configure the master to have no executors, and run builds only on slaves. Also, slaves that are connected to Jenkins gain the full access to the entire Jenkins build cluster, since a slave can send code to the master to be executed. |
Securing Jenkins
Skip to end of metadata
Go to start of metadata
Comments (2)
Oct 17, 2008
dmulter - says:
I understand the security implications on the master, but what is meant by slave...I understand the security implications on the master, but what is meant by slaves being able to send code to the master for execution? Can a slave build script specify actions to be executed on the master? I thought distributed builds worked by running the build on a (mostly) replicated copy of the master environment and returning results back to the master. Maybe I lack details on the whole master/slave interaction during a build. More details on this and security will help to assess the best security tradeoffs.
Mar 19, 2014
Robert Berger says:
It would be wonderful if someone could show how to setup and enable security pro...It would be wonderful if someone could show how to setup and enable security programmatically with Groovy or the CLI.
I can find examples of how to set up user authentication but not how to do the base enabling of security
Add Comment