Nordlicht Reisen GmbH, a fictional travel agency, is growing: Three teams work on the booking portal (website, payment, operations), and two external people from an agency join them who are supposed to work only on the website. So far every person is an "administrator", because that causes the fewest follow-up questions. Last week someone accidentally deleted a service connection to production. You are to arrange the permissions in GitHub and in Azure DevOps so that every person may do exactly what their task requires, and so that this can be managed with a few groups.
The exam calls this: planning permissions and roles in GitHub and permissions and security groups in Azure DevOps, assigning access levels and structuring projects and teams. The focus is a decision by the principle of least privilege: Who gets which role at which place, and why no more.
Prior knowledge: The principle of least privilege for Azure roles is covered in K3, lesson 3.3.5; you know role assignments in Azure (Azure RBAC) from AZ-104, module 2. This lesson is about the permissions in the two development platforms, not about permissions on Azure resources. The permissions of an identity in pipelines are in lesson 5.1, protection rules for branches in lesson 2.2 and permissions in the repository in lesson 2.4.
GitHub: roles in the organization and the repository
GitHub separates two levels, and confusing them is the most common source of errors: roles in the organization (what someone may manage in the organization) and roles at a repository (what someone may do with the code and its settings).
Roles in the organization
According to GitHub, these predefined roles exist:
| Role | What it can do according to GitHub |
|---|---|
| Owner | full administrative access to the organization; GitHub advises limiting the role, but not to fewer than two people |
| Member | the default role without administrative permissions; by default, members can create repositories and projects |
| Moderator | a member who can additionally block strangers, limit interactions and hide comments |
| Billing manager | manages payment settings, without further access |
| Security manager | sees security alerts, manages security features and reads all repositories of the organization |
| GitHub App manager | manages the registrations of the organization's GitHub Apps, but does not install or remove apps |
| Outside collaborator | access to one or more repositories without being a member of the organization (consultants, temporary staff) |
According to GitHub, custom organization roles (for example with the single permission "View organization audit log") exist only with GitHub Enterprise Cloud. For Nordlicht Reisen that means: The agency people are Outside collaborators, not members; that way they see only what is explicitly released to them.
Roles at the repository
The role determines access to a single repository. GitHub describes five predefined roles from least to most:
| Role | Recommended by GitHub for |
|---|---|
| Read | everyone who does not change the code but wants to view or discuss it |
| Triage | contributors who manage issues, discussions and pull requests without write permission |
| Write | contributors who actively push to the project |
| Maintain | project leads who manage the repository without access to sensitive or destructive actions |
| Admin | whoever needs full access, including sensitive and destructive actions (for example managing security settings or deleting the repository) |
Custom repository roles also require GitHub Enterprise Cloud. In addition, organization owners set base permissions that apply to all members at every repository of the organization; owners have admin access to every repository of the organization. So choose the base permission as low as your teams can bear, and raise the permissions per team.
Teams
A team mirrors the structure of your company, manages access to repositories and sends notifications. According to GitHub:
- Only members of the organization can be in teams; outside collaborators cannot. They get their permissions directly at the repository.
- Owners and team maintainers can give a team admin, read or write access to repositories of the organization.
- Teams can be nested: A parent team can have several child teams, a child has exactly one parent team, and child teams inherit the repository permissions of the parent team. GitHub advises checking existing access before nesting, giving the parent team only permissions that are safe for everyone below it, and assigning more sensitive permissions further down.
- In the file
CODEOWNERS, teams can be owners of code areas (lesson 2.2). Visible teams see and mention all members of the organization, secret teams only their members and the owners.