Security Scenario 3: Small Open Source
The Saga Continues…
Previously I’ve put together two scenarios on security. These were:
Both of these scenarios covered in-house development projects. In this scenario I’m going to change tack and look at a small open source project.
Petros has been working on an open source project called Midas for about a year now. This project is hosted on SourceForge, and he is the only administrator. However recently it’s been getting some press and other people have volunteered to help, which he thinks is wonderful!
He has convinced his work (a chemical conversion company) to host a CruiseControl.Net instance for the community to use. However, he doesn’t want to allow everybody full access to the server. He is happy to let everybody view the current status, but he only wants to let approved developers force build. He doesn’t want to let anybody stop or start the projects. Finally he wants to know who performs any release builds.
The Build Setup
Petros’s build setup is really simple – there is only two projects in his config.
The first project is a CI build – it polls every five minutes and performs a build if any changes are detected. This does the standard compile, run unit tests and generate installer. The outputs are stored in a publically accessible location.
The second project is a releasing build. Again it does the compile, unit tests, etc, except this time in release mode. The outputs are then stored on his open source website and a release post is added to tell the world. This project must be manually forced.
The Goals
Since Petros has full access to the server and is the only person who needs access, there will be only one security zone.
This security zone will grant approved developers access to force or abort a build on the project. Currently security does not prevent viewing the reports, so this will not require configuration.
To keep things simple, all force builds will be audited.
The Plan
There will be only one security group – CanBuild. This group will have force build access to both projects, but no other access.
All developers who need force build rights will be manually added to this group.
The Configuration
The full configuration is as follows:
<cruisecontrol><project name="Open_Source(Build)"><workingDirectory>C:\Build\OSB</workingDirectory><artifactDirectory>C:\Build\OSB\Deploy</artifactDirectory><webURL>http://localhost/server/local/project/LAS-Main/ViewProjectReport.aspx</webURL><triggers><intervalTrigger buildCondition="IfModificationExists" seconds="300"/></triggers><publishers><xmllogger/></publishers></project><project name="Open_Source(Deploy)"><workingDirectory>C:\Build\OSD</workingDirectory><artifactDirectory>C:\Build\OSD\Deploy</artifactDirectory><webURL>http://localhost/server/local/project/LAS-Main/ViewProjectReport.aspx</webURL><triggers><intervalTrigger buildCondition="IfModificationExists" seconds="300"/></triggers><publishers><xmllogger/></publishers></project></cruisecontrol>Again the first step is turning on security – just added the internalSecurity element, plus the users and permissions children.
Adding the Roles and Users
Now the security has been added the next step is to add the users and the CanBuild security group. Since this is an open source project, Petros doesn’t want to bother with much security. Therefore each person who is allowed to build has been added as a password user. At the moment, this is only Petros himself:
<users><passwordUser name="petros" password="whoareyou"/></users>The role is very similar, but just contains the force build permission and the list of users:
<permissions><rolePermission name="all" defaultRight="Deny" forceBuild="Allow"><users><userName name="petros"/></users></rolePermission></permissions>I’ve also set the default right on the internal security element to Deny, so everyone else will be unable to do a force build.
Locking Down the Projects
The final step for preventing force builds is to secure the projects. This is the same configuration as previous:
<security type="defaultProjectSecurity"><permissions><rolePermission name="all" ref="all"/></permissions></security>Again, this checks that the user is in the role, and if so the user can do a force build. All other permissions are denied at the server level.
Audit Logging
The final step once more is the auditing. Since this is very simple, I’ve just added the default audit logger block:
<audit><xmlFileAudit/></audit>I haven’t added an audit reader as there is no way of accessing it at the moment.
Some Comments
Again, there’s still no way of allowing password users to log onto the dashboard (hence why I haven’t covered it).
One issue I did think about with this scenario is sending the login requests to a remote service (e.g. something like SourceForge or CodePlex). At the moment I don’t know whether these services even have a login API, but if so it would be nice to have a pass-through for this. However since it opens up a whole set of security issues I decided not to even try it!
