Cruise was built from the bottom up to be a completely secure system. Cruise Server provides both an http service and an https service by default (the http service listens on port 8153 and the https service listens on port 8154).
Agent approval and communication
Whenever a Cruise Agent is set up and pointed to a Cruise Server, it will appear on the agents tab. However you'll need to approve it before it can start doing work. When you click "approve", Cruise Server will create an X509 certificate and sends it to the Agent. The Agent will then use this certificate to communicate with Cruise Server in future. Cruise Server stores the md5 signature for this certificate in its configuration file and uses it to verify the identity of that agent in all subsequent requests.
In some rare circumstances, for example if you delete Cruise Server's certificate truststore or keystore by doing a complete uninstall of Cruise and then a fresh install, Server - Agent communication can fail. If this happens, you may be able to resolve the issue by deleting the Agent's configuration from Cruise Server's configuration file. If this fails, you'll have to go into your Agent and delete its certificate stores, or doing a complete uninstall and reinstall.
By default, Cruise does not require users to authenticate. However we provide two mechanisms for you to force users to authenticate if you wish to. Either you can create a file that Cruise Server can use to authenticate log in requests, or you can have it talk to an LDAP or ActiveDirectory server.
You can use both password file and LDAP / AD authentication. In this case Cruise will first try and authenticate you against the password file. If it cannot find your username, or if it finds that your username and password do not match, it will try LDAP / AD next. This can be very useful if you need a read-only user that can be used by scripts, and you do not want to add this user to your LDAP.
File based authentication
The simplest way to authenticate people is to create a password file for Cruise to use. This is just a plain text file with the following format:
[username]:[password hashed with SHA1 and encoded with base 64]
If your SHA1 algorithm and base 64 encoding works properly, the word "badger" should come out as "ThmbShxAtJepX80c2JY1FzOEmUk=".
You can use the htpasswd program from Apache to manage your password file. You must use the -s option with htpasswd to force it to use SHA1 encoding for the password. So for example, you can use the following command to create a password file called "passwd" and put the password for the user "user" in it:
htpasswd -c -s passwd user
You can put as many username / hashed password pairs as you like -- use a new line for each one.
Tell Cruise where the password file is using the following entry in the configuration file:
<cruise> <server> <license ... /> <security> <passwordFile path="[path to password file]"/> </security> </server> </cruise>
As usual, Cruise should pick up this change immediately and start authenticating new users (note that anybody already using Cruise will be required to authenticate).
The file format for the password file is the standard one for Java Properties, which means in particular that spaces, the equals sign and the colon are special characters in the username and must be escaped with a backslash.
LDAP / ActiveDirectory authentication
Cruise can be made to authenticate against any standard LDAP / AD server. Cruise uses the standard JNDI APIs to access LDAP / AD, with some help from the Acegi Security framework. Cruise can only use "bind" authentication, in which it authenticates directly to the LDAP / AD server.
You can use the following configuration to get Cruise to talk to your LDAP / AD server:
<cruise> <server> <license ... > <security> <ldap uri="[LDAP server URI]" managerDn="[LDAP server manager DN]" managerPassword="[LDAP server manager password]" searchBase="[LDAP search base]" searchFilter="[LDAP search filter]"/> </security> </server> </cruise>
The manager DN is the LDAP / AD manager user's DN, used to connect to the LDAP / AD server.
The manager password is the LDAP / AD manager user's DN, used to connect to the LDAP / AD server.
The search base is the name of the context or object to search in for the user record.
The search filter is the expression used in the user search. It is an LDAP search filter as defined in RFC 2254 with optional parameters -- in this case, the username is the only parameter. An example might be:
which would search for a username match on the uid attribute, or
which would search for a username match on the sAMAccountName attribute (for ActiveDirectory users)
The authentication operation has two steps: firstly, Cruise uses the managerDn and managerPassword supplied to search for the user using the searchBase and searchFilter attributes. By default Cruise will search subtrees and time out after five seconds. Cruise then uses the DN returned to attempt to bind to LDAP / AD using the username and password supplied by the user.
Note that Cruise doesn't retrieve any further information from LDAP / AD such as roles, groups or email address. It simply gets the user's CN.
With no security switched on, there is of course no authorisation either. Once you have switched on security, the default is that any user can perform any operation. However you can get Cruise to limit certain operations to administrators, and specify which users should belong to the administrator group.
<cruise> <server> <license ... /> <security> <passwordFile path="/etc/cruise-server/passwords.properties" /> <roles> <role name="qa"> <user>dyang</user> <user>pavan</user> </role> <role name="cruise_admin"> <user>jhumble</user> <user>qiao</user> </role> </roles> <admins> <role>cruise_admin</role> <user>chris</user> </admins> </security> </server> </cruise>In this example, the "qa" role has two users: dyang and pavan. The "cruise_admin" role also has two users: jhumble and qiao. The <admins> section of the configuration controls who is allowed to administer Cruise. We discuss it in the following section.
Cruise allows you to restrict the users who can perform certain functions. Only administrators are allowed to use the administration tab, and hence to change Cruise's configuration. Furthermore, only administrators can manage Cruise's build cloud.
The "admins" section is optional -- without it, all users are automatically made administrators. If you do include the admins section, only users and roles specified within it can administer Cruise.
In the example in the section above, members of the "cruise_admin" role (jhumble and qiao), along with the user chris, can administer Cruise.
If administrators are specified, only they can perform the following actions:
- Access the "administration" tab
- Add pipelines
- Approve agents
- Add / remove agent resources
In Cruise, it is possible to specify manual approvals between stages. From Cruise 1.1, you can specify who is able to trigger manual approvals. In the example below, only members of the role "qa", and the user "jerry", can trigger the approval.
<stage name="uat"> <approval type="manual"> <auth> <role>qa</role> <user>jerry</user> </auth> </approval> <jobs> <job name="deploy"> <resources> <resource>uat</resource> </resources> <tasks> <ant target="deploy" /> </tasks> </job> </jobs> </stage>