AZ-400: Designing and Implementing Microsoft DevOps Solutions

Design and Implement Authentication and Authorization Methods

Design and implement permissions and security groups in Azure DevOps

In this lesson, we explore best practices for designing and implementing permissions and security groups in Azure DevOps. Securing access and enforcing role-based access control (RBAC) are essential for protecting your DevOps resources and ensuring smooth project management.

Organizational User Management

Start by navigating to your Azure DevOps organization. On the lower left-hand side, click on Organization Settings, then select Users to view all the users in your organization. You may see entries like "Jeremy at KodeKloud.com," "Jeremy Morgan at Gmail.com," and "BreakTheBuild at Outlook.com."

To add a new user, click Add Users. You can add either individual users or service principals by:

  • Entering their email addresses.
  • Selecting an access level (Basic, Stakeholder, or Visual Studio Subscriber).
  • Assigning them to specific projects.

Important

Note that email notifications are only sent to users, not to service principals.

The image shows a user management interface in Azure DevOps, displaying a list of users with their access levels and an "Add new users" panel on the right.

Project Settings and Administrators

Proceed by selecting the project you wish to manage; for example, choose the "Simple Converter" project under the KodeKloud demo section. Once inside the project, click Project Settings located in the lower left-hand corner. Here, you can manage project administrators along with other settings. You might see project administrators such as Lloyd Christmas and Jeremy Morgan.

The image shows the project settings page for "SimpleConverter" on Azure DevOps, displaying project details, administrators, and Azure DevOps services.

To add new administrators or adjust permissions, search for users and groups, and assign them accordingly.

Teams and Permissions Overview

Within Project Settings, you can also view and manage team configurations. The default project team (e.g., "Simple Converter team") displays its members and administrators. Although you may already be an administrator, additional users like "Break the Build" can be added to the team as needed.

The image shows a project settings page from Azure DevOps, displaying a list of user groups and their permissions within a project called "SimpleConverter." Each group has a description of its permissions, such as managing builds or accessing the team project.

When you click on Build Administrators, you will see detailed permission options. Many settings may appear as "Not Set." Typical permissions include:

  • View Project Level Information
  • Create Tag Definitions
  • Manage test runs and configurations

The image shows a project settings page from Azure DevOps, specifically the permissions settings for build administrators. It includes various permission options like deleting projects, managing properties, and handling work items.

Members of the Build Administrators group generally have limited rights, such as accessing analytics and managing test-related tasks. Their permissions are restricted to prevent sensitive operations like deleting or renaming the project.

The image shows a project settings page for "SimpleConverter" on Azure DevOps, displaying permissions for build administrators with various options set to "Deny" or "Not set."

Security Warning

Always grant only the minimal permissions necessary. If a user is temporarily added to the Build Administrators group for a specific task, ensure their access is revoked once the task is complete. Be cautious when merging groups, as inherited permissions can lead to unintentional access.

Creating Custom Security Groups

Creating custom security groups allows you to tailor permission sets for specific roles. For example, you might create a group called "JavaScript Developers" and add members like Lloyd Christmas. By default, these groups inherit permissions from Project Valid Users (e.g., View Analytics). You can then customize permissions, such as allowing the creation of tag definitions or test runs.

The image shows a project settings page in Azure DevOps, displaying a list of permission groups and a pop-up window for creating a new group named "Javascript Developers."

The image shows a project settings page for "SimpleConverter" on Azure DevOps, displaying a list of user groups and their permissions. Each group has a description of its access level and role within the project.

Granular Permission Management

For roles requiring highly specific access control, you can explicitly allow or deny individual permissions. For instance, you can establish a test group where a member (e.g., Jeremy Morgan) is only granted access to view project-level information while all other actions are explicitly denied.

The image shows a project settings page in Azure DevOps, displaying various permission settings for a project named "SimpleConverter." The settings include options to allow or deny actions like deleting the project, editing information, and managing properties.

This level of granular management helps you avoid overprivileging users and ensures that everyone gets only the access necessary for their role. Regular auditing of these permissions is essential to remove outdated or unnecessary access rights, thereby bolstering your security posture.

Additional Areas of Security

Azure DevOps also provides advanced security settings for other critical areas:

  • Repos: Manage and review access to code repositories.

  • Pipelines: Control build and release pipeline permissions. Within the pipeline view, click the three dots (more actions) and select Manage Security. This allows you to restrict users (e.g., readers) to view-only access for pipelines and builds.

    The image shows an Azure DevOps interface with a "Pipelines" section and a permissions window for "SimpleConverter," detailing various user group permissions.

  • Contributors: This group generally has broader permissions, such as creating or deleting build pipelines and builds; however, certain permissions like "destroy builds" may be explicitly denied to avoid accidental loss of data.

Regular audits across these sections are critical. Audit logs in Azure DevOps can be used to monitor changes, ensuring that your security policies remain compliant.

Summary

By following these best practices—granting only necessary permissions, explicitly denying unwanted actions, and conducting regular audits—you maintain a secure Azure DevOps environment. This approach not only supports daily operations but also helps in compliance during audits.

Thank you for reading this lesson. We hope you now have a clearer understanding of implementing and managing permissions and security groups in Azure DevOps.

Useful References

Watch Video

Watch video content

Previous
Design and implement permissions and roles in GitHub