Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Hudson-ci/Using Hudson/Securing Hudson"
< Hudson-ci | Using Hudson
m (Securing Hudson moved to Using Hudson/Securing Hudson) |
|||
| (2 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| − | + | {{hudson|pageTitle=Securing Hudson}} | |
| − | + | ||
| − | + | ||
| − | + | ||
In the default configuration, Hudson does not perform any security check. This means any person accessing the website can configure Hudson and jobs, and perform builds. While this configuration is normally acceptable for intranet use, Hudson can be also configured to authenticate users and enforce access control so that it can be exposed to the untrusted environment, such as the internet. | In the default configuration, Hudson does not perform any security check. This means any person accessing the website can configure Hudson and jobs, and perform builds. While this configuration is normally acceptable for intranet use, Hudson can be also configured to authenticate users and enforce access control so that it can be exposed to the untrusted environment, such as the internet. | ||
This setting is controlled mainly by two axes: | 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. | + | # '''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 Hudson run its own user database, and perform access control based on the permission/user matrix. | 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 Hudson run its own user database, and perform access control based on the permission/user matrix. | ||
| − | == | + | == Topics == |
| − | [http://wiki.hudson-ci.org/display/HUDSON/Quick+and+Simple+Security Quick and Simple Security ]— if you are running Hudson like "java -jar hudson.war" and only need a very simple set up | + | * [http://wiki.hudson-ci.org/display/HUDSON/Quick+and+Simple+Security Quick and Simple Security ]— if you are running Hudson like "java -jar hudson.war" and only need a very simple set up |
| + | * [http://wiki.hudson-ci.org/display/HUDSON/Standard+Security+Setup Standard Security Setup] — discusses the most common set up of letting Hudson run its own user database and do finer-grained access control | ||
| + | * [http://wiki.hudson-ci.org/display/HUDSON/Apache+frontend+for+security Apache frontend for security] — run Hudson behind Apache and perform access control in Apache instead of Hudson | ||
| + | * [http://wiki.hudson-ci.org/display/HUDSON/Authenticating+scripted+clients Authenticating scripted clients] — if you need to programatically access security-enabled Hudson web UI, use BASIC auth | ||
| + | * [http://wiki.hudson-ci.org/display/HUDSON/Disable+security Help! I locked myself out!] — if something goes really wrong and you can't get full access anymore | ||
| − | == Security | + | == Security Implications == |
| − | Note that even when security is enabled, builds that are performed in Hudson still | + | Note that even when security is enabled, builds that are performed in Hudson still retain the full access to the entire system, because they run as different processes. This implies any committor to any of the projects built in Hudson has full access to the system. They can change the build script to look at any files in the system that Hudson has access to, and modify them. |
Also, if you are using the master/slave mode, slaves that are connected to Hudson also gains the full access to the entire Hudson build cluster, since a slave can send code to the master to be executed. | Also, if you are using the master/slave mode, slaves that are connected to Hudson also gains the full access to the entire Hudson build cluster, since a slave can send code to the master to be executed. | ||
On the other hand, Hudson does not escape any input strings. You can use any HTML tags and also someone can embed harmful scripts. Appropriate security settings must be required.<br> | On the other hand, Hudson does not escape any input strings. You can use any HTML tags and also someone can embed harmful scripts. Appropriate security settings must be required.<br> | ||
Latest revision as of 08:06, 11 July 2014
| Hudson Continuous Integration Server | |
| Website | |
| Download | |
| Community | |
| Mailing List • Forums • IRC • mattermost | |
| Issues | |
| Open • Help Wanted • Bug Day | |
| Contribute | |
| Browse Source |
|
Securing Hudson |
|---|
In the default configuration, Hudson does not perform any security check. This means any person accessing the website can configure Hudson and jobs, and perform builds. While this configuration is normally acceptable for intranet use, Hudson can be also configured to authenticate users and enforce access control so that it can be exposed to the untrusted environment, such as the internet.
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 Hudson run its own user database, and perform access control based on the permission/user matrix.
Topics
- Quick and Simple Security — if you are running Hudson like "java -jar hudson.war" and only need a very simple set up
- Standard Security Setup — discusses the most common set up of letting Hudson run its own user database and do finer-grained access control
- Apache frontend for security — run Hudson behind Apache and perform access control in Apache instead of Hudson
- Authenticating scripted clients — if you need to programatically access security-enabled Hudson web UI, use BASIC auth
- Help! I locked myself out! — if something goes really wrong and you can't get full access anymore
Security Implications
Note that even when security is enabled, builds that are performed in Hudson still retain the full access to the entire system, because they run as different processes. This implies any committor to any of the projects built in Hudson has full access to the system. They can change the build script to look at any files in the system that Hudson has access to, and modify them.
Also, if you are using the master/slave mode, slaves that are connected to Hudson also gains the full access to the entire Hudson build cluster, since a slave can send code to the master to be executed.
On the other hand, Hudson does not escape any input strings. You can use any HTML tags and also someone can embed harmful scripts. Appropriate security settings must be required.