Securing CruiseControl.Net integration server
Wednesday, August 8, 2007 at 1:01PM CruiseControl.NET is a great open source tool for continuous integration (CI). Yet, the default settings are quite permissive, and unless you're working on an open source project as well, you might prefer restrict the accesses to your sole team. I have found that securing CruiseControl.Net while keeping a developer-friendly environment is not such an easy task. This post is a summary of the various steps needed to secure your CI server. It should work against CCNET 1.2 and 1.3.
Create a dedicated Windows User for CCNET
There is (probably) no reason for your integration process to run as a administrator on your CI server. Running the CI as an administrator is just asking for more trouble if something goes wrong in the build process. First create a dedicated Windows account, I suggest to name it integration for the sake of simplicity. Then, From Start » Administrative Tools » Services, you can change the properties of the running services named CruiseControl.Net server, in the Log On tab. Just define the newly created account to be used for the CCNET service. You will also probably need to grant some Windows directory permission on root integration directory.
Restrict CCNET remoting access to localhost
Unless you're having a farm of build servers with a webserver dedicated to reporting the various build statuses, the CCNET remoting endpoint should not be remotely accessible (yet, that's the default CCNET settings). This behavior can be adjusted by changing the ccnet.exe.config file. Replace the line <channel ref="tcp" port="21234" > with <channel ref="tcp" port="21234" rejectRemoteRequests="true" >. Now, only a local CCNET dashboard instance is able to connect to the CCNET remoting endpoint.
Restrict CCNET Dashboard access to logged users
By default, no access restrictions are put on the CCNET Dashboard. The most simple way of restricting the access to the dashboard panel is to add a windows authentication layer within the ASP.NET application. You can add the following lines to the webdashboard\web.config configuration file to do that:
<authentication mode="Windows" />
<authorization>
<deny users="?" />
<allow users="*" />
</authorization>
Re-opening the CCTray status
CCTray does not support any kind of authentication, thus both Remoting and Via Web Dashboard connection methods will fail now that we have purposely put access restrictions. The trick consists in changing again the webdashboard\web.config to allow anonymous access to XmlServerReport.aspx with
<location path="XmlServerReport.aspx">
<system.web>
<authorization>
<allow users="?" />
</authorization>
</system.web>
</location>
Then, configure CCTray with Via CruiseControl.Net Dashboard to connect to the URL http://myserver/XmlServerReport.aspx. Note that your build statuses (i.e. "Success" or "Failure") will be publicly available to anybody, yet it's not an issue to disclose such a limited information.