KBEC-00466 - CloudBees CD AD and LDAP group use - best practices

What are some best practice considerations for the use of AD/LDAP groups with CD?

When it comes to AD/LDAP groups, the two areas for consideration are:

Configuring Access Control Limitations or ACLs allows you to define rights for 4 types of privileges:

a) Read

b) Modify

c) Execute

d) Permissions

Further details can be found at View and change access control privileges on objects.

ACLs can be set for users, groups or other system objects. While the CD service offers a built-in set of users and groups, most companies will eventually configure their existing Directory Management system to work with CD to define their ACLs. In some companies, group creation does not always follow a rigourous process, and the questions on how best to manage access for tools like CD can require direct discussions with the Directory Management team to formulate a process and plan for defining groups. Generally speaking, AD/LDAP servers tend to perform less effectively when group sizes get very large. Ensuring expectations around ACLs in tools like CD are understood will help the tool to be configured best to work effeciently.

While user-specific ACLs can be used to grant/block access, as a best practice, it is generally recommend that Groups be used in the majority of cases, and that such ACLs be setup as early as possible in your solution planning process.

Here is an example on why groups over individual users can help gain efficiencies: Whenever someone leaves a company, or moves to a new role that adjusts their responsibilities, the use of Group based ACLs will make addressing such organizational changes easier to manage inside the CD solution. Suppose the intent is to make sure that only the existing manager, Bob Smith, can alter the definitions of a particular project on the production system. Entering an ACL for "Bob Smith" that defines the appropriate permissions may achieve your immediate requirement, but you may also find that various objects (other procedures, pipelines, resources etc…​) inside other projects may also need to be setup with permisssions for Bob. Later, if Bob moves on, to be replaced by, Mary Lee, each of these placed ACLs would require manually updating to place Mary’s ACL wherever Bob existed. Instead, if a group had been used for these ACLS, let’s call this group "Manager_X_product", for which Bob was a member, then simply replacing Bob with Mary inside this AD/LDAP group may be all that is required. Similarly, perhaps there is an overlap time period where both Bob and Mary will need to share these permissions until the formal transition of responsibilities is completed. Rather than adding Mary at all locations where Bob’s ACL exists today, simply adding Mary to the existing "Manager_X_Product" group inside of AD/LDAP will ensure that this change is handled with a simple and clearly understood modification inside of your AD/LDAP system.

When configuring your AD/LDAP setup, you can choose to allow recursive group selection separately for both Email recipients and the list of approvers. In order for either of these options to be used, however, you first must have the "Recursively Traverse Group Hierarchy" activated.

The general recommendation would be for all 3 of these settings to keep their default setting (active):

Recursively Traverse Group Hierarchy Include Nested Group Users in Notifications Include Nested Group Users as Approvers

Please refer to the User Authentication section of the online help to understand how nested groups will process the set of users when a parent group is selected with these nested group options.

eg: Your QE-team might contain hundreds of employees working on various products. An approval on Product X for a "QE stage", should ideally be based on those who work with Product X, and not all members in the QE team.
So splitting up this larger set of "QE-Team" Users to instead define sub-groups that represent the product may be one way to define smaller subsets. Yes, some people may need to reside in multiple groups, but ensuring AD/LDAP offers these smaller levels of granularity will help your AD/LDAP overall performance for use with CD and possibly other cross-company tools that require group based authentication as well.

Project_X — manager1 — manager2 --QE_Group --- QE_member1 --- QE_member2 --DEV_Group --- DEV_member1 --- DEV_member2

You may be fine with any one of these 6 individuals approving your pipeline to proceed, but you generally prefer that this responsibility lie with the managers of this group. By allowing group traversal to exist for approvers, any of the members inside "Project_X" will be able to approve a gate/manual task. However, by not allowing traversal to exist for emails, selecting the "Project_X" group will ensure that only "manager1" and "manager2" are sent a reminder about having to approve this pipeline. This can avoid excess "spam" emails on the broader team as pipelines proceed during the day while still allowing members of the QE_Group or DEV_Group to make approvals directly when they see something falling behind, or if their manager asks them to "allow that task to go through". For this small example size, this choice may not be quite so critical, but as the size of the QE_Group or DEV_Group expands over time, reducing noise like this can be deemed helpful for your team to keep better focus.

As in the previous case, this may require you to work with your Directory Provider team, to design a more detailed structure for the sub-teams that are working with your CD pipelines.