Securing a build definition is quite straight forward when an organization uses multiple team projects in VSTS/TFS to handle different applications they develop. Each team project build administration can be assigned to different individuals easily. There are organizations using a single team project to manage all of their applications, dividing them into teams inside a single team project. Let's look at possibilities of securing each application teams' builds in single team project for organization scenario.
Builds can be organized into folders in VSTS/TFS. This gives you opportunity to create each build definition belonging to a different application teams in relevant folder for the team. For the folder only, the team members should be given access to edit build quality, view or queue a build. To do this follow the steps below.
Create a folder for each of the application teams in your team project using the Manage Folders window in the build definitions page of VSTS/TFS.
Open the relevant build folder security page.
Add the team to the permissions and you can see the team inherits permissions from contributors group of team project (If you have created teams without inheriting permissions of contributors group then the inherited permissions would not be available).
Set the permissions below to explicitly allow for the team to enable them to view, edit build quality and queue builds.
Once you have completed this procedure for all the teams in the team project, go to the all builds security options from the build definitions page. Then for the contributors VSTS group set the permissions to "Not Set" for all permission options. This will remove the inheritance of permission via contributors group to a team's build folders for members of other teams, to view, queue or set build quality.
We managed to isolate the permissions for view, set build quality and queue builds for the individual teams, for their respective builds following the steps above. But how can we apply build administration permissions isolated to each team? Let's have a look at that next.
No one should be added to the Build Administrators VSTS security group, except people who require administrative control for all build definitions.
Create Build Admin VSTS group for each of the project teams and make each one a member of the relevant project team. For each team build folder grant permissions to the relevant team build admin group, as “allow” for all permissions, except "Override check-in validation by build" and "Update build information" which should only be allowed for service accounts (for more information refer here). Queue, set quality and view permissions are inherited to admins of a given team from the team since we are making the build admin VSTS group a member of the relevant team.
You can add the required build admin groups to the administrator role of the required build queues. You may keep the contributors group as user for build queues shared for all teams. If you have a build queue specific to a single team the you can remove the contributors group from that queue, and just add the relevant team with user role to the queue.
Another essential part of managing build definitions is the ability to create service endpoints to get external service access vial builds. For example, if you want to integrate with SonarQube for validation your source code quality with the builds, you need to create service endpoint to connect to Sonar Server or Sonar cloud services. For this you need end point creation and end point administration permissions to be granted for the build administration VSTS groups you have created. One caveat is this allows the ability to change the other teams’ endpoints to another teams build administrators. With the current permissions structure of VSTS/TFS there is no way to create the end point administration and creation permissions isolated to each team inside a team project.
No comments:
Post a Comment