Разрешения по умолчанию возвращаются в очереди AzDevOps
Локальный сервер AzDevOps Server 2019, версия Dev17.M153.5. Я ограничил права доступа по умолчанию к очередям агентов для каждого проекта в каждой отдельной коллекции - удалил набор по умолчанию (Release Admins/Build Admins/Project Admins), добавил некоторые другие строки (Server Admins).
Теперь, время от времени, периодически без какого-либо паттерна, который я вижу, эти три разрешения продолжают автоматически возвращаться. В разных проектах, без вмешательства человека (всем людям, имеющим на это права, было сказано), эти три строки с ролью администратора снова появляются в ACL очереди агента по умолчанию.
Это известное поведение в AzDevOps? Есть ли способ отказаться?
РЕДАКТИРОВАТЬ: вот как это выглядит. Первые три строчки не принадлежат.
РЕДАКТИРОВАТЬ: согласно совету, я бы попытался отследить его с помощью журнала активности. Я пошел и сделал фиктивное изменение безопасности очереди по умолчанию в другом месте. Была запись в журнале с командойSecurityRoleAssignments.SetRoleAssignments. Затем я отфильтровал журнал активности в коллекции, в которой были восстановлены разрешения, и поискал ту же команду. Нет экземпляров. Журнал заканчивается около 14 июля, что, вероятно, предшествует событию.
1 ответ
Это должно быть вызвано разрешением на наследование. По умолчанию параметр "Наследование" включен, и к роли администратора "Все пулы агентов" добавляются следующие группы: "Администраторы сборки", "Администраторы выпуска", "Администраторы проекта".
Если мы отключим параметр "Наследование", мы сможем удалить группы разрешений по умолчанию (Release Admins/Build Admins/Project Admins).
Если мы включим наследование, группа разрешений будет снова унаследована, и группы разрешений по умолчанию вернутся, проверьте эту опцию и подтвердите, что наследование всегда отключено. Пожалуйста, также подтвердите со всеми людьми, имеющими право обновлять эту опцию.
Uodate1
Войдите в систему {URL-адрес сервера Azure DevOps}/_oi/_diagnostics/activityLog, мы сможем увидеть журнал активности и проверить, кто добавил группы разрешений, проверьте его.
Установлен Azure DevOps 2020. Через пару недель такого поведения нет.
В заключение, это была ошибка в AzDevOps 2019, которую они тихо исправили.