Azure DevOps group assignment to projects management

1
votes

Group assignment to projects gives different end result based on how assignment was done:

  1. If a group rule is created and access is granted to a project - access can also be removed in group rule settings, projects can have an AD group assigned as a member.

  2. If a group rule is created for AD group and same AD group needs additional permissions configured (let's say deny access to pipelines) - AD group has to be added as a member to a DevOps group (In this case DevOps group does not have a group rule). Then, there are 3 possibilities:

    • assign project to group rule (as in scenario 1), then DevOps group would not be used and would only act as permission group

    • DevOps group can be added to project from project settings.

    • AD group can be added to project from project settings.

    In last two cases - AD group rule has an inherited assignment to that project and it cannot be removed from group rule settings.

  3. A group rule can be created for the DevOps group, and that DevOps group can have AD group as a member. There is a same problem that if this group is added to a project from project settings - access cannot be revoked in group rule settings. It's a bit better than option 2 because you have a group and a group rule for the same group, but then access level management is done not on AD group level but on DevOps group level. 4.There can be a case there AD group has a group rule and belongs to a DevOps group that has a group rule as well, but I guess that shouldn't be a case in real life setup

How should access to projects be managed? Should all access be managed from organization level using groups/user assignment? Or should it be managed in project level by adding members? From the description above, I can see that having a hybrid of both can result in a mess and a lot of confusion when some access can be revoked in org User settings and some cannot. What is the recommended practice here?

In project settings user has access to DevOps groups and all AD groups (AFAK based on AD permissions) when adding a member to a team. Is it possible to control that from DevOps part? So that user could only add DevOps groups, or AD groups that have Group rule created for them? It might be related to the question above, but what is the recommended practice here?

====== Adding a scenario to illustrate the my questions

Let's take this scenario: AD groups "Devs" and "QA" need to be granted access to DevOps and projects P1 and P2.

  1. P1 proj admin can go into proj settings -> teams and add AD Group "QA" directly to project. Since QA is not part of the org yet, I would argue that this action should be not allowed. Is it possible to prevent admins from doing that? Any arguments why it should be allowed?
  2. Global admin (GA) adds Group rule to add AD group "Devs" to DevOps. DevOps Group is not created for this rule so AD group has to be added to a new or existing DevOps group. Let's say a new Group "DevOps-Devs" is created and AD group is added as a member to it. Now P2 owner wants to add developers to a project. He/she can add both AD "Devs" and "DevOps-Devs" in project settings. I would guess that DevOps group should be used, is that right? (again how can adding AD group be prevented?)
  3. GA creates a DevOps group called DevOps-QA. He then adds a group rule for that group. AD group "QA" is then added as a member to DevOps-QA. Which method (2 or 3) is preferred or recommended for creating group rules? Then instead of adding members to project through proj settings, a project access is assigned to DevOps-QA group in Group rules settings -> Manage group rule

Additionally, I would argue that user/ad group access to projects should be mainly managed in Organization settings. This is not the case if 1 and 2 options are used. If option 3 is used, access can be added or revoked from group in "manage group rule" settings, however it was mentioned that group rules are mainly used for licensing (and they have to be created in a first place), so now it looks that it's not the best place to manage access. Not having an opinion on this and allowing users use their preferred way can lead to more confusion future organization management. What approach can you recommend?

1
azure-devops

1 Answers

1
votes

Group rules are used mainly for licensing. @alictai has provided an explanation in this link:

Azure DevOps includes group-based licensing for Azure Active Directory (Azure AD) groups and Azure DevOps group so you can assign an access level or extensions to a group. Resources in Azure DevOps are assigned to all members of the group. This enables organization administrators to easily automate their licensing policies.

The licenses are assigned upon users' first sign-in to the organization, as available, so that large groups are not arbitrarily assigned an insufficient license count. Users who have taken up a license will be reflected in the Users list. If you would prefer to explicitly manage all licenses without group rules, and have all users immediately materialize in your Users list, then you must add them individually.

The Permissions tab on the group details are provided as a convenience for viewing what the group, and consequently any users (once they sign into the organization) in the group have access to.

Update:

  1. As your organization has been connected to Azure Active Directory, you can reuse the Azure AD groups to manage permissions in bulk for your organization. Just add those groups to the group that you want. Adding the QA group to a particular team project, the members can only be able to access the resources in this team project. To create and manage Azure AD groups, you need Azure AD administrator permissions or have the directory administrator delegate those permissions to you in the Azure portal. If you don't want to Project Administrator to add Azure AD groups, you can don't grant them Azure AD administrator permissions or directory administrator delegate.

https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/manage-azure-active-directory-groups?view=azure-devops&tabs=preview-page

  1. You can don't grant project admins Azure AD administrator permissions or directory administrator delegate.

  2. A Group Rule is not required for this, you can use either one. If you want to add folks from one group to another group, you can add the whole group to the parent group. As users get added to the child group they automatically get added to the parent group.

https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/organization-management?view=azure-devops