Search code examples
permissionsazure-devopsadoreadonly

Azure DevOps make project read only

We have some old ADO/VSTS projects that we want to archive and make read only. Each project has work items, builds, git repos, etc...

at the moment the only methods I have found are painful.

  1. Remove all groups except read only group and add users in there. this is too painful and long, we have over 300 projects to make read only
  2. Create a new group and then add in other groups (e.g. proj admins, contributors etc..) and then add this group to the top level area/git repo path and set all to DENY. *

I tried this with git repos and There is some issues with this as some permissions are not inherited down to individual users who created the git repo and they are still able to checkin.

Here you can see I created a READONLY group and set everything to DENY except Read permissions. (The members of this group are the default groups e.g. contributors, build admins, proj admins)

enter image description here

However, I had a repo created by a test user BEFORE i created the readonly group and it seems that user still has permissions to that repo

enter image description here

ok ok I understand that if the permissions are set at the lower level, then they won't be inherited down from the top level parent. I could create a script that checks the users of every git repo and sets their check-in permissions to deny but that is painful and i would prefer not to do that. Likewise, some projects have over 300 git repos.

FYI I want to make the whole project read only not just git repos.

Solution

  • Yeah, you've found one of the nasty features of the Azure DevOps permission model. More specific ACLs trump less specific ACLs. Even for DENY rules.

    When there is an explicit ALLOW rule on a more specific ACL, it will override the DENY on a less specific ACL.

    Specificity for git is based on:

    1. Server (TFS only)
    2. Organization / Project Collection
    3. Project
    4. Default repo settings
    5. Specific repo settings
    6. Branch folder settings (only settable through API)
    7. Specific branch settings

    Similar hierarchies exist for other securables.

    There is no easy way to strip these all, apart from scripting the action.

    The Azure CLI has a devops extension which will allow you to script out what you want and can output JSON to make it easier to script.

    You can use az devops security permission list to list all permissions defined for a identity (group or user) and az devops security permission reset or az devops security permission update to unset or override the given permission.

    Other probably needed calls: