Какого рода контекст безопасности получают пользовательские задачи выпуска TFS?

Question

TFS 2018u1.У меня есть пользовательская задача Powershell, которая вызывает службы TFS через объект VSSConnection:

$VSS = Get-VssConnection -TaskContext $distributedTaskContext
$Client = $VSS.GetClient(...)

Вопрос: какой контекст безопасности получает задача?Это определенно не учетная запись агента.Чтобы убедиться, что я настроил временный экземпляр агента, который запускается от имени меня, администратора TFS, и пользовательская задача, выполняемая на этом агенте, не имеет полного администратора.

Основная проблема - яЯ пытаюсь получить текущую запись агента из задачи, и задача видит только один пул, хотя у нас их несколько.См. этот ответ .

Answer 1

Во-первых, distributedTaskContext не подключается к TFS с NTLM, как предполагает ответ Патрика Лу. Соединяется с Authorization:Bearer и токеном. Я использовал тот же токен для вызова конечной точки /_api/_common/GetUserProfile, которая возвращает текущего пользователя и вернула следующую идентификационную запись:

{
    "IdentityType": "user",
    "FriendlyDisplayName": "Project Collection Build Service (TEAM FOUNDATION)",
    "DisplayName": "Project Collection Build Service (TEAM FOUNDATION)",
    "SubHeader": "Build\\233e4ccc-d129-4ba4-9c5b-ea82c7ae1d15",
    "TeamFoundationId": "7a3195ee-870e-4151-ba58-1e522732086c",
    "EntityId": "vss.ds.v1.ims.user.7a3195ee870e4151ba581e522732086c",
    "Errors": [],
    "Warnings": [],
    "Domain": "Build",
    "AccountName": "233e4ccc-d129-4ba4-9c5b-ea82c7ae1d15",
    "IsWindowsUser": false,
    "MailAddress": ""
}

Похоже, это некая искусственная идентификация, которую TFS создает именно для этой цели. Если заглянуть в базу данных TFS в таблице tbl_Identity, можно найти множество пользовательских записей с такими именами - по одной на коллекцию, а также некоторые, относящиеся к конкретному проекту.

Этот пользователь принадлежит к группе уровня сервера, называемой «Группа служб безопасности» (а также к группе уровня коллекции с тем же именем). Эти группы принадлежат, соответственно, Действительным пользователям Team Foundation и Действительным пользователям коллекции проектов и ничему другому.

По крайней мере на уровне сбора «Группа служб безопасности» видна и содержит много учетных записей.

Все эти пользователи «Службы сборки» принадлежат домену «Сборка». Домен не является субъектом безопасности, однако вы не можете предоставлять права на домен.

Говоря об объемах OAuth. Я использовал тот же токен для вызова доморощенной страницы "каковы области действия этого токена" , и оказалось, что у токена distributedTaskContext есть ровно один - app_token. Это действительная область, которая открывает все конечные точки и все методы (см. список динамических областей ). Параметр scopes в манифесте расширения не имеет к этому никакого отношения; это влияет только на вклады на стороне клиента.

---

Однако, когда дело доходит до видимости пула, история хитрая. Похоже, что все учетные записи «Служба сборки коллекций проектов» принадлежат действительным пользователям, но предоставление роли «Чтение» во всех пулах действительным пользователям не открывает их для API REST в задачах. Предоставление Reader явным образом «Службе сборки коллекций проектов» делает. Однако существует множество подобных учетных записей (кажется, по одной на коллекцию) - и предоставление Reader открывает пулы только для выпуска определений в коллекции, в которой они находятся. Чтобы задачи в выпусках во всех коллекциях могли читать пулы, вам нужно пройти через все коллекции и предоставить Reader для каждой из них «Службе сборки коллекций проектов».

Answer 2

Я пытаюсь получить текущую запись агента из задачи, и задача видит только один пул, хотя у нас их несколько.

Существует Роли безопасности пула агентов , например, с Администратор Роль, вы можете:

Зарегистрируйте или отмените регистрацию агентов в пуле и управляйте членством для всех пулов , а также просмотр и создание пулов. Они также могут использовать пул агентов при создании очереди агентов в командном проекте. Система автоматически добавляет пользователя, который создал пул к Роль администратора для этого пула.

Права по умолчанию для агента сборки, выполняющего задачу выпуска, должны совпадать с учетной записью службы сборки . Добавьте свою учетную запись службы сборки в роли безопасности пула агентов для Администратора из контекста уровня администратора на странице Пулы агентов. Затем попробуйте снова.

Еще одна возможность, которой вам не хватает в области vso.agentpools в задаче настройки выпуска.

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

Подробнее см. На Поддерживаемые области