Assign Azure DevOps and GitHub Permissions
Evaluate Azure DevOps Access Tiers
Azure DevOps provides different access levels for users, and you should choose the one that gives each person just enough permission to do their job. The Stakeholder level is for users who only need to view and track work items, like a project manager. The Basic access level is for team members who need full access to features like code, builds, and test plans. Users with a Visual Studio subscriber license get the same access as Basic, but this is included with their Visual Studio subscription. You evaluate a user's role and assign the lowest access tier that meets their needs, which follows the security principle of least privilege.
Analyze GitHub Outside Collaborator Scopes
When you need to give someone outside your organization access to a GitHub repository, you assign them an outside collaborator role. These roles define what they can do. The Read role lets a person view the repository's content and code. The Write role allows them to make changes, like creating branches and pushing code. The Admin role gives them full control, including managing repository settings and other collaborators. You analyze the external contributor's responsibilities and grant only the scope necessary, such as Read for a reviewer or Write for an active developer, to maintain security.
Service Principals and Identity Credentials
For automated processes, like those run by GitHub Actions, you use a service identity instead of a user account. You create a service principal in Azure for each application environment (like Dev, Test, or Prod). This service principal acts as an identity for the automation. To let GitHub Actions securely use this identity, you configure a federated identity credential. This credential creates a trust relationship between your GitHub repository and the Azure service principal, allowing secure, password-less authentication for your workflows.
StudyCerts
StudyCerts