venerdì 11 maggio 2012 14:08
I'm posting a similar question to this other post I made.
But, from a different angle.
I recently viewed Brian Randell's talk on Team Build 2010 from the TechEd conference on May 2011.
During his talk, about 32 minutes into, he mentioned that he consulted for a company that needed to have Team Projects have their own dedicated Build Controllers for security purposes. He indicated that this was possible to do, but so far I have not been able to set up such a scenario. Doing this would help out my issue in the post above.
Could a more knowledgeable forum member guide me to the steps to do this? Of course, if Brian monitors this forum, I'll take his input as well. ;)
Appreciate the help!
Tutte le risposte
venerdì 11 maggio 2012 16:10
venerdì 11 maggio 2012 17:53
I've worked with several customer who have done this. Basically they have a fine grained security model where each build definition uses agent tags that are specific to each team project. Additionally build/test controllers and agents are setup using different service accounts for each team project and only the users of Team Project know the password for their build service account and not the passwords of the other service accounts setup for other projects.
You're going to need to spend a good amount of time locking down the build agents and controllers via TFSSecurity but it is possible.
The approach we've taken isn't elegant (it relies on security which is a bit ugly) but it works.
Take a look at these TFSSecurity command lines: http://intovsts.net/2009/09/03/more-fine-grained-permissions-in-tfs2010/
Now Brian Randell is a world renowned TFS Wizard and he could have gone down the path of using the TFS API to enable the end result of 1 controller - per - team project.
I'll let him chime in if he has a code drop he could provide. Needless to say taking a dependency on 3rd party code/customizing TFS via the API may not be something your IT overloads will allow and hence the approach of using TFS Security doesn't have those issues. :-)
venerdì 11 maggio 2012 18:40
Thank you for the responses.
It would be an honor just to have Brian reply to my post... even if all he did was Emoticon reply. ;)
Ian, I'm the TFS Admin at one of your former clients... I see your name all over the place in the history of work items and source control. Small world, huh?
I can't write it here for security reasons but reply back if you are curious...
Okay, so I don't take up more room on MS fourms with personal stuff...
The lockdown of the controllers is fine with me... if the users needs to provide a unique account and password to run builds on a particular controller, then so be it. As i eluded to in my first post, the goal is to have only certain users deploy to certain environment to satisfy policies.
I'll begin working in that direction and we what I can come up with.
Always welcome additional information if anyone feels like sharing.
Apprecaite it, Thank you!
lunedì 14 maggio 2012 17:56
Ian's suggestion almost works, but I'm not seeing where the users of a team project have exclusive rights to a build controller... or where a Build controller is setup per team project.
Yes, it appears that you can prevent users from making more build controllers and agents, but you can't seem to prevent users with build definition permission from choosing any of the build controllers that have been established... ones with higher permissions on the build service account given to that controller.
Seems like a user with access to build definitions on at least one team project can summon the build controller of another team project... which is the problem I wish to avoid.
We'd like to give a group of Build Def writers access to a team project with a designated Build Controller that no other Team Project Build Def writers would have access to. But, I'm unclear how to do this.
Is there a way to have one Controller = one Team Project?
mercoledì 13 giugno 2012 20:03Hey Ron, have you had any luck with this? I'm looking into doing something similar.