CODEWITHSUNDEEP
tfsazure-pipelines-release-pipelinerelease-management
Josto
Josto

Reputation: 243

Excesive permission level in release management for contributors group in TFS

It seems that the default permission mapping on TFS Release Management (TFS 2017) for Contributors group allows to do much more things than a simple "contributor" should be allowed to do: enter image description here Of course permissions can be changed (depending of the number of TP´s this can take a while) but I don´t understand why the default mapping gives so many power. As far as I understand, Contributors group is intended to put developers. Why should a developer has permissions to change/delete a release environment, manage the release aprovers or even modify a release definition? (which probably has been properly configured by a release administrator).

Am I missunderstanding anything?

Curiously,the team build permissions for contributors are much more restricted...

Regards.

Upvotes: 0

Views: 247

Answers (1)

Leo Liu
Leo Liu

Reputation: 76770

Excesive permission level in release management for contributors group in TFS

Sorry for any inconvenience.

This behavior is by designed and is not a issue. According to the document Pipeline permissions and security roles, we could to know:

Once you have been added as a team member, you are a member of the Contributors group. This allows you to define and manage builds and releases. The most common built-in groups include Readers, Contributors, and Project Administrators. These groups are assigned the default permissions as listed below.

enter image description here

As we can see that the different default permissions between build and release is the option to build default permissions will have one more task Manage build queues and build qualities (Others are not show in the list of ACCESS CONTROL SUMMARY).

So, when we got to the default permission mapping on TFS Build Management, we can see following settings:

enter image description here

Although the other options except the red box are set to not set, they allow membership in the group with the permission set to take precedence. If you check those options one by one, you will find all those permission are set as Allow (inherited), check the image from Azure Devops:

enter image description here

So, the team build permissions for contributors are not restricted than TFS Build Management.

Besides, if you feel the default mapping of contributors gives so many power, you can add a custom group and set the permissions for this group, then add those contributors to this group.

Hope this helps.

Upvotes: 2

Related Questions