Scenario 2: Large In-house Development Team¶

Background¶

The company Acme Banking, a large multi-national bank. Lu is the manager of the lending application software development department and has a staff of 19 people working for him. He has charged his system admin, Peter, with securing CruiseControl.Net.

Some background, Lu is responsible for three applications: lending applications system (LAS), load approval and tracking system (LATS) and bad debt analysis and recovery system (BARS). Each system is an independent web application with a complex set of business rules and a backing database. To allow interactions between the system each application exposes web services. Finally each application has a number of support tools that are Windows-based.

However, to simplify things, Lu's department is only responsible for development. The QA department is responsible for all testing (including deployments) and the Server department is responsible for the actual deployment to PROD. All of these deployments are done via hand-overs, with the receiving department responsible for getting the binaries from the build server.

As for department structure, each team has a team leader and a senior developer. There are also between two and six junior developers in each team. Peter is not included in any of the teams as his full-time role is supporting the developers. All staff are on the same network and have windows logins.

Lu wants to limit access for project to the team that is responsible for it. No team is allowed access to any project that belongs to another team. Additionally only the team leader and senior developer are allowed to start/stop the projects, although the junior developers can force builds. Everything done in the system must be audited.

The Build Setup¶

Each application has two projects - main and tools. Main includes the actual web application, plus the web services, while tools contains all the support tools. This makes a total of six projects.

Each project contains everything required to build the binaries and deploy them to the build server (for the other departments). These are triggered on an interval basis, plus every night at 3am.

Since the hand-over process is manual, there is no impact on other environments. However considering the team size and low-level of trust they want everything locked down.

The Goals¶

There will be three security zones: low, medium and high. The following table shows these zones:

Zone	Description	Projects	People
Low	Permission to force/abort builds.	All	Junior developers
Medium	As above, plus permission to start/stop projects.	All	Team leaders and senior developers
High	As above, plus access to security information.	n/a	Lu & Peter

Each application will be divided into low and medium zones. The high level security zone is generic to the system rather than application-specific.

The Plan¶

These goals give a total of seven security groups - low and medium for each application plus a high security group. Everybody within the department will belong to one of these seven groups.

This actual model is a little more complex, but I've put together a diagram as follows:

The Configuration¶

Since I'm looking at the security, not the actual projects, I'm going to use the following general configuration for each project:

 1<project name="LAS-Main">
 2  <workingDirectory>C:\Build\LAS-Main</workingDirectory>
 3  <artifactDirectory>C:\Build\LAS-Main\Deploy</artifactDirectory>
 4  <webURL>http://localhost/server/local/project/LAS-Main/ViewProjectReport.aspx</webURL>
 5  <!-- Source control block defined here -->
 6  <triggers>
 7    <intervalTrigger buildCondition="IfModificationExists" seconds="300" />
 8  </triggers>
 9  <tasks>
10    <!-- Tasks defined here -->
11  </tasks>
12  <publishers>
13    <!-- Publishers defined here -->
14  </publishers>
15</project>

The project name (i.e. LAS-Main) will be changed for each project - a total of six projects.

Again the first step is turning on security - just added the internalSecurity element, plus the required children.

Turning On Security¶

First, I'm going to turn on security for the server. This involves adding a security block to the config file. Since the security will be defined internally, I'm going to use the <internalSecurity> definition:

 1<cruisecontrol>
 2  <internalSecurity>
 3    <users>
 4    </users>
 5    <permissions>
 6    </permissions>
 7  </internalSecurity>
 8  <!-- Projects defined here -->
 9</cruisecontrol>

Now the config file passes validation and security has been turned on for the server. But, all this has done is completely lock down the server, so no one can do anything\!

Adding Some Roles and Users¶

Next, I added the users. Since everyone is on the network I added them with ldapUser elements. This is defined as follows:

 1<internalSecurity>
 2  <users>
 3    <ldapUser name="lu.jones" domain="localhost"/> <!-- Manager -->
 4    <ldapUser name="peter.smith" domain="localhost"/> <!-- SysAdmin -->
 5    <ldapUser name="mark.doulos" domain="localhost"/> <!-- LAS Team leader -->
 6    <ldapUser name="jill.white" domain="localhost"/> <!-- LAS Senior developer -->
 7    <ldapUser name="john.asher" domain="localhost"/> <!-- LAS Junior developer -->
 8    <!-- Remaining users omitted -->
 9  </users>
10  <permissions>
11  </permissions>
12</internalSecurity>

Note there is a domain in here - I've just changed it to localhost for this example. Without the domain the active directory authentication will fail as the authenticator won't know where to look.

I've also added a server-level permission for the high-security permissions:

 1<internalSecurity>
 2  <users>
 3    <ldapUser name="lu.jones" domain="localhost"/> <!-- Manager -->
 4    <ldapUser name="peter.smith" domain="localhost"/> <!-- SysAdmin -->
 5    <ldapUser name="mark.doulos" domain="localhost"/> <!-- LAS Team leader -->
 6    <ldapUser name="jill.white" domain="localhost"/> <!-- LAS Senior developer -->
 7    <ldapUser name="john.asher" domain="localhost"/> <!-- LAS Junior developer -->
 8    <!-- Remaining users omitted -->
 9  </users>
10  <permissions>
11    <rolePermission name="Admin" defaultRight="Allow">
12      <users>
13        <userName name="lu.jones"/>
14        <userName name="peter.smith"/>
15      </users>
16    </rolePermission>
17  </permissions>
18</internalSecurity>

This just says that Lu and Peter have full access to everything.

Locking Down Projects¶

The final step is to lock down the projects. This is where there is slightly more work than scenario one. Since each project needs to be secured, every project will need to be modified.

There are two ways this can be done. One way would be to add the security to each project, the second is to define roles and then link each project to them. Since there are two projects for each application, with identical permissions I'm going to use the second approach.

In the internalSecurity element I define each application role. The following shows an example:

 1<internalSecurity>
 2  <users>
 3    <!-- Omitted for brevity -->
 4  </users>
 5  <permissions>
 6    <rolePermission name="Admin" defaultRight="Allow">
 7      <users>
 8        <userName name="lu.jones"/>
 9        <userName name="peter.smith"/>
10      </users>
11    </rolePermission>
12    <rolePermission name="LAS-Developers" forceBuild="Allow" defaultRight="Deny">
13      <users>
14        <userName name="john.asher"/>
15        <!-- Remaining users omitted -->
16      </users>
17    </rolePermission>
18    <rolePermission name="LAS-Admin" forceBuild="Allow" startProject="Allow" defaultRight="Deny">
19      <users>
20        <userName name="mark.doulos"/>
21        <userName name="jill.white"/>
22      </users>
23    </rolePermission>
24    <!-- Remaining roles omitted -->
25  </permissions>
26</internalSecurity>

Then, in each project I add a security section like the following:

 1<project name="LAS-Main">
 2  <workingDirectory>C:\Build\LAS-Main</workingDirectory>
 3  <artifactDirectory>C:\Build\LAS-Main\Deploy</artifactDirectory>
 4  <webURL>http://localhost/server/local/project/LAS-Main/ViewProjectReport.aspx</webURL>
 5  <!-- Source control block defined here -->
 6  <triggers>
 7    <intervalTrigger buildCondition="IfModificationExists" seconds="300" />
 8  </triggers>
 9  <tasks>
10    <!-- Tasks defined here -->
11  </tasks>
12  <publishers>
13    <!-- Publishers defined here -->
14  </publishers>
15  <security type="defaultProjectSecurity" defaultRight="Deny">
16    <permissions>
17      <rolePermission name="LAS-Developers" ref="LAS-Developers"/>
18      <rolePermission name="LAS-Admin" ref="LAS-Admin"/>
19      <rolePermission name="Admin" ref="Admin"/>
20    </permissions>
21  </security>
22</project>

The first two permissions will change to match the application each project is for, while the last one is the same for all projects (gives Peter & Lu access to the projects).

Audit Logging¶

Finally Lu wants everything audited. This is very simple to do, just add an audit logger and an audit reader. This is done in the internalSecurity element by adding the following elements:

 1<internalSecurity>
 2  <audit>
 3    <xmlFileAudit/>
 4  </audit>
 5  <auditReader type="xmlFileAuditReader"/>
 6  <users>
 7    <!-- Omitted for brevity -->
 8  </users>
 9  <permissions>
10    <!-- Omitted for brevity -->
11  </permissions>
12</internalSecurity>

By default these will use an audit log called SecurityAudit.xml in the same directory as the executables. This can be changed by added a location attribute as follows:

 1<internalSecurity>
 2  <audit>
 3    <xmlFileAudit location="C:\Logs\CCNet_Audit.xml"/>
 4  </audit>
 5  <auditReader type="xmlFileAuditReader" location="C:\Logs\CCNet_Audit.xml"/>
 6  <users>
 7    <!-- Omitted for brevity -->
 8  </users>
 9  <permissions>
10    <!-- Omitted for brevity -->
11  </permissions>
12</internalSecurity>

Note that the location must be on both elements and they point to the same location. This is because the two items work independently of each other and it is possible to have multiple audit loggers.

And that's the security settings for this scenario - the full example, the duplicate projects are omitted since this scenario is focusing on the security.

 1<cruisecontrol>
 2  <internalSecurity>
 3    <audit>
 4      <xmlFileAudit location="C:\Logs\CCNet_Audit.xml"/>
 5    </audit>
 6    <auditReader type="xmlFileAuditReader" location="C:\Logs\CCNet_Audit.xml"/>
 7    <users>
 8      <ldapUser name="lu.jones" domain="localhost"/> <!-- Manager -->
 9      <ldapUser name="peter.smith" domain="localhost"/> <!-- SysAdmin -->
10      <ldapUser name="mark.doulos" domain="localhost"/> <!-- LAS Team leader -->
11      <ldapUser name="jill.white" domain="localhost"/> <!-- LAS Senior developer -->
12      <ldapUser name="john.asher" domain="localhost"/> <!-- LAS Junior developer -->
13      <!-- Remaining users omitted -->
14    </users>
15    <permissions>
16      <rolePermission name="Admin" defaultRight="Allow">
17        <users>
18          <userName name="lu.jones"/>
19          <userName name="peter.smith"/>
20        </users>
21      </rolePermission>
22      <rolePermission name="LAS-Developers" forceBuild="Allow" defaultRight="Deny">
23        <users>
24          <userName name="john.asher"/>
25          <!-- Remaining users omitted -->
26        </users>
27      </rolePermission>
28      <rolePermission name="LAS-Admin" forceBuild="Allow" startProject="Allow" defaultRight="Deny">
29        <users>
30          <userName name="mark.doulos"/>
31          <userName name="jill.white"/>
32        </users>
33      </rolePermission>
34      <!-- Remaining roles omitted -->
35    </permissions>
36  </internalSecurity>
37  <project name="LAS-Main">
38    <workingDirectory>C:\Build\LAS-Main</workingDirectory>
39    <artifactDirectory>C:\Build\LAS-Main\Deploy</artifactDirectory>
40    <webURL>http://localhost/server/local/project/LAS-Main/ViewProjectReport.aspx</webURL>
41    <!-- Source control block defined here -->
42    <triggers>
43      <intervalTrigger buildCondition="IfModificationExists" seconds="300" />
44    </triggers>
45    <tasks>
46      <!-- Tasks defined here -->
47    </tasks>
48    <publishers>
49      <!-- Publishers defined here -->
50    </publishers>
51    <security type="defaultProjectSecurity" defaultRight="Deny">
52      <permissions>
53        <rolePermission name="LAS-Developers" ref="LAS-Developers"/>
54        <rolePermission name="LAS-Admin" ref="LAS-Admin"/>
55        <rolePermission name="Admin" ref="Admin"/>
56      </permissions>
57    </security>
58  </project>
59  <!-- Other projects defined here -->
60</cruisecontrol>

Credits¶

This scenario was originally posted on Automated Coder