Author

I am Joannes Vermorel, founder at Lokad. I am also an engineer from the Corps des Mines who initially graduated from the ENS.

I have been passionate about computer science, software matters and data mining for almost two decades. (RSS - ATOM)

Meta
« Velib's from a software engineer viewpoint | Main | RESX utilities open-sourced »
Wednesday
Aug082007

Securing CruiseControl.Net integration server

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.

Reader Comments (3)

[...] Joannes Vermorel’s blog » Blog Archive » Securing CruiseControl.Net integration server 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. (tags: dev howto continuousintegration tools security) [...]

December 18, 2007 | Unregistered Commenterlinks for 2007-12-17 « d

stoppable coop iwath contracting isbn vaidya formulations unemployment jaoa madagascar subscribing inland Saimlorektos Polapompos

October 19, 2009 | Unregistered Commenterbuy ambien no prescription

We have Cruise Control server running on a server in a (hosted) dedicated server environment. There is a domain available. Any pointers as to how I could restrict access to domain users only?

Thanks

- Andrew

November 17, 2009 | Unregistered CommenterAndrew Heys
Comments for this entry have been disabled. Additional comments may not be added to this entry at this time.