Каков правильный способ создания субъекта-службы для конечной точки службы VSTS Azure Resource Manager?
Для развертывания из VSTS в службу приложений Azure необходимо определить конечную точку службы Azure Resource Manager в VSTS. Для этой конечной точки службы вам понадобятся:
- идентификатор подписки
- идентификатор клиента
- идентификатор клиента субъекта-службы
- субъект службы
Первые два очевидны, но для субъекта-службы это менее прямолинейно. -вперед. В различных статьях предлагается зарегистрировать новое приложение в Azure AD, создать ключ доступа к API для приложения и установить роль участника для автоматически созданного пользователя. Идентификатор приложения и (скрытое) значение ключа затем можно использовать для заполнения двух последних полей.
Это работает, но у меня такое чувство, что это неправильный способ. Одна из причин заключается в том, что при регистрации приложения запрашивается URL-адрес для входа, который для VSTS вообще не нужен. Вторая причина заключается в том, что это зарегистрированное приложение не служит никакой цели, кроме предоставления субъекта-службы. Фактические приложения - это службы приложений Azure.
Это так, как задумано, или есть лучший способ получить субъект службы для конечной точки службы VSTS?
Да, это правильный способ. Принцип работы сервиса, по сути, является приложением или идентификатором приложения, и вы используете некоторые возможности того, что это приложение, такие как предоставление доступа к API и так далее. Необходимость в URL-адресе - это похмелье от тех дней, когда приложения, где не существовало только веб-приложений и сервисных принципов, и, возможно, это можно было бы сделать необязательным, но это еще не так, так что вы обычно просто придумываете его.
.