At Nordlicht Reisen GmbH, a fictional travel agency, someone accidentally committed and pushed an access key for the payment system into the booking portal's repository last week. On top of that comes the question of who may set tags or delete branches at all, and what to do when someone overwrites a file. You are to set the permissions and describe the procedure for both cases.
The exam names four skills: repository permissions, tags, recovering specific data with Git and removing specific data from source control.
Prior knowledge: Why a secret never belongs in the code, and how the pipeline reaches Azure without a secret, is taught in K3, lesson 3.3.3 (never print secrets) and 3.7.5 (deploying without a secret). How versions come from tags is in K3, lesson 3.7.4. You know the protection rules for branches from lesson 2.2; roles and groups as a whole follow in module D5.
Permissions in Azure Repos
Microsoft's page on repository permissions describes it like this: you set permissions at the level of All Repositories (applies to every Git repository of the project) or for a single repository; individual repositories inherit from the entry at project level. Branches inherit a subset of the repository's permissions (branch permissions have a page of their own). Microsoft describes the path like this: Project settings, Repositories, then either All Repositories or the repository, in each case Security. For that you need Manage permissions; members of the Project Administrators group have it by default.
The permissions and the default groups
| Permission | What it is for | By default |
|---|---|---|
| Read | clone, fetch, read; also create, comment on and vote on pull requests | Readers, Contributors, Build Administrators, Project Administrators |
| Contribute, Create branch, Create tag, Manage notes | contribute, create branches and tags | Contributors and above |
| Create repository, Delete repository, Rename repository | manage repositories | Project Administrators |
| Edit policies, Manage permissions, Remove others' locks | policies, permissions, other people's locks | Project Administrators |
| Bypass policies when completing pull requests, Bypass policies when pushing, Force push (rewrite history, delete branches and tags) | bypass and rewrite | not set for any group |
The last row is the most important: by default, Microsoft sets the dangerous permissions for nobody. That means even the Project Administrators would first have to give them to themselves. Since an update of Azure DevOps, the creators of a branch also no longer automatically receive Edit policies; you grant it explicitly.
Allow, Deny, Not set
Microsoft explains three states:
- Not set grants and denies nothing; a permission from another group or from a higher level can still apply.
- Allow grants the permission, unless a more specific Deny overrides it.
- Deny usually overrides Allow, including permissions that are inherited or given through other groups, and it affects all members of the group.
Check group memberships and inheritance before you set Deny. You switch a repository's inheritance to On or Off under Inheritance. Microsoft's advice: write down the setting beforehand and afterward check with an affected person that access is correct; whoever switches off inheritance loses permissions from the project level.
Bypassing policies
There used to be a single permission, "Exempt from policy enforcement". It allowed both bypassing when completing a pull request and a direct push. Two permissions replace it: Bypass policies when completing pull requests (only when completing) and Bypass policies when pushing (direct push to branches with required policies). As examples of occasional bypassing, Microsoft names reverting a change that breaks the build, and a hotfix in the middle of the night. Whoever had the old permission before received both new ones; check this, and leave the push permission Not set if it is not needed.