TFS 2010 Build Controller Security

Question

Dear Microsoft,

My company is migrating to TFS 2010 SP1 (finally)...

I appreciate the changes you've made to build security where the Team Build definitions now have access control where it didn't before.  The gives us more options to prevent users from altering builds.

But, I noticed that in viewing Build Controllers, any and all Build controllers that are setup within our network show up on the list of available build controllers.  This means that anyone with Build Definition access appears to be able to direct there builds to go to any available Build Controller.

Unless I'm missing something, this is a potential security problem for us as we have a model the will have Build Agents with different levels of Network Access beyond the build itself.

Specifically, our build processes will deploy to different environments and currently our build agents are run under different Build Service accounts... each with its own level of access to these environment. 

Example: Development Build Agents  with Developent Build Service accounts will compile and deploy to Dev Servers,  Itegration Build Accounts build to CI Servers, etc...

My question is:

Is there anyway to lock down the Build Controllers so that only certain users can queue builds on them?

The only workaround that I saw was to create different Team Project Collections and have separate Build Controllers in those, but that is not practical as we want all users in one collection.

Please advise and thanks for the help!

Ron

Answer 1

Hi Ron, 

Thanks for your post.

As far as I know, there’s no a way to set permissions on TFS Build Controllers so that only certain users can queue builds on them.  

For this scenario, I suggest you submit it as a suggestion to User Voice site at: http://visualstudio.uservoice.com/forums/121579-visual-studio. Microsoft engineers will evaluate them seriously. 

---

John Qiao [MSFT]
MSDN Community Support | Feedback to us

Answer 2

Thank you for the response, John.

I must now reply in disbelief...

Wow. 

So we solved one issue with security on the locking up builds with permissions, but opened up a bigger one by letting any and ALL Team projects in a Collection have access to all the Build Controllers with no way of setting permissions on them.  At least in 2008 you could isolate build agent to Team Projects and limit access this way, but that is gone.

So, a developer with limited access to a Prod server but admin access to setup their developer builds and use a discoverable Build Agent that can deploy changes via  the build controller services account that does have access to that Prod server?  Is this what I'm reading?

Kind of a big loophole wouldn't you think?

Only workaround I see is that I'd need to make a whole new Collection to get this security...  I'm hoping that there is something else that can be done here.

I'll voice my concern to the User Voice area... but would like to know of a workaround now.

Thank you,

Ron

Answer 3

Hi Ron, 

Thanks for your reply.

In this scenario, when create the Build Definition for project, you can specific the Build Controllerin Build Definition>>Build Defaulttab. And give some build admin users the Edit build definition permission, not all can create and edit the Build Definition to change build controller.      

---

John Qiao [MSFT]
MSDN Community Support | Feedback to us

Answer 4

Hi John,

Thank you for the offer of a workaround.

However, this is not quite ideal.

The scenario we are trying to accomplish, which works fairly well in TFS 2008, is to allow developers to create there own builds for the Dev environments because of limited Build User resources.   The Build Users we have are of a certain level of trust for auditing purposes and construct builds for higher level environments.  This was accomplished by using a dedicated Team Project for Build Users with Agents created for there use.  Since discovery was limited to Agents in Team Projects, the higher level build agents with different Service Credentials are used only for the Build Users.

In TFS 2010, The Build Controllers are seen by one and all.  Now, Developers will not be able to create their own builds and this will put a strain on Build Users resource time.

Oh, and Developers with the ability to run builds can choose any Controller that they want in the Drop Down from the Queue Build dialog.  Defaulting to a certain controller doesn't prevent selection.  So, this negated the workaround you suggested.  I spent a little time with a group of users in a test environment for TFS 2010 and confirmed these facts.

So, this leaves us with the open problem of security.  Any other workarounds you can suggest?

By the way, I did find the proposed idea in Users Voice... if anyone else thinks that security on this in important, I'd advise voting on this topic.

http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2314935-tfs-2010-build-controllers-agents-security

Thank you,

Ron

Answer 5

Hi Ron, 

Thanks for your reply.

I suggest you create your new request in User Voice site for this scenario(set permissions on Build Controller level).

It seems there’s no other better workaround except yours which to create different Team Project Collections.  

---

John Qiao [MSFT]
MSDN Community Support | Feedback to us

Answer 6

Hi John,

Thank you for the reply, but this was not an answer to the issue.  This is still a problem, I'd like this post to remain open to see if anyone else has a better solution to offer instead of sweeping this one under the rug.

Creating another Team Project collection doesn't solve the problem because source control and work items do not cross Team Collections.

TFS 2010's ability to have all team projects in a collection discover all build controllers has made the problem worse.  You cannot even isolate the build agents to team projects like you used to in TFS 2008.

What else can be done here? 

Thank you,

Ron

Answer 7

Ron,

Did your organization find a solution to this security issue? I am attempting to overcome the same problem... I like the idea of production deployments via Team Build/WebDeploy, but need to be able to limit production controller access to the release management team.

Thanks,
PJ

Answer 8

Hi PJ,

We are plugging forward with different collection for the different levels and assigning different levels of Build Controllers to them.

Also, we have just locked down Team Build in our main collection to only build admin for working on all defintions and restricted the contributors to only run them.

Good luck!

Ron