Azure DevOps сделать проект доступным только для чтения - PullRequest
1 голос
/ 17 января 2020

У нас есть несколько старых проектов ADO / VSTS, которые мы хотим заархивировать и сделать только для чтения. У каждого проекта есть рабочие элементы, сборки, git репозитории и т. Д. c ...

. На данный момент единственные методы, которые я нашел, являются болезненными.

  1. Удалите все группы, кроме группы только для чтения, и добавьте туда пользователей. это слишком больно и долго, у нас есть более 300 проектов, чтобы сделать их только для чтения
  2. Создайте новую группу и добавьте ее в другие группы (например, администраторы proj, contributors и т. Д. c .. ), а затем добавьте эту группу в область верхнего уровня / git путь репо и установите для всех значение DENY. *

Я пытался сделать это с git репозиториями, и с этим есть некоторые проблемы, поскольку некоторые разрешения не наследуются отдельным пользователям, создавшим репо git, и они все еще могут для проверки.

Здесь вы можете видеть, что я создал группу READONLY и установил для DENY все, кроме прав на чтение. (Членами этой группы являются группы по умолчанию, например, участники, администраторы сборки, администраторы proj)

enter image description here

Однако у меня есть репо, созданный с помощью теста Пользователь ДО того, как я создал группу только для чтения, и кажется, что у пользователя все еще есть разрешения на это репо

enter image description here

ок, хорошо, я понимаю, что если разрешения установлены на нижний уровень, то они не будут наследоваться от родительского верхнего уровня. Я мог бы создать скрипт, который проверяет пользователей каждого репо git и устанавливает для них разрешения на регистрацию, чтобы запретить, но это болезненно, и я предпочел бы не делать этого. Кроме того, некоторые проекты имеют более 300 git репо.

К вашему сведению, я хочу сделать весь проект доступным только для чтения, а не только git репозитория.

1 Ответ

2 голосов
/ 17 января 2020

Да, вы обнаружили одну из неприятных особенностей модели разрешений Azure DevOps. Более точные c ACL имеют больший приоритет, чем c ACL. Даже для правил DENY.

Если в более конкретном c ACL есть явное правило ALLOW, оно будет переопределять DENY в менее конкретном c ACL.

Специфичность для git основан на:

  1. Сервер (только TFS)
  2. Организация / Коллекция проектов
  3. Проект
  4. Настройки репо по умолчанию
  5. Специфика c Настройки репо
  6. Настройки папки филиала (настраивается только через API)
  7. Специфика c Настройки филиала

Аналогичные иерархии существуют для других защищаемых объектов .

Нет простого способа убрать все это, кроме написания сценария действия.

Azure CLI имеет расширение devops , которое позволит вам создавать сценарии того, что вы хотите, и может выводить JSON, чтобы упростить создание сценариев.

Вы можете использовать az devops security permission list для отображения всех разрешений, определенных для удостоверения (группы или пользователя) и az devops security permission reset или az devops security permission update для отмены или отмены данного разрешения.

Возможно, требуется другое звонки:

...