Использование личных маркеров доступа

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019 | TFS 2018

Вы можете использовать личный маркер доступа (PAT) в качестве альтернативного пароля для проверки подлинности в Azure DevOps. В этой статье мы покажем, как создавать, использовать, изменять и отзывать PAT для Azure DevOps.

Сведения о личных маркерах доступа

Личный маркер доступа содержит учетные данные безопасности для Azure DevOps. Личный маркер доступа определяет вас, доступные для вас организации и области доступа. Таким образом, они столь же важны, как пароли, поэтому их следует рассматривать так же.

Если вы работаете в средствах Майкрософт, то использование учетной записи Майкрософт (MSA) или Azure Active Directory (Azure AD) является приемлемым и хорошо поддерживаемым подходом. Но если вы работаете со сторонними инструментами, которые не поддерживают учетные записи Майкрософт или Azure AD, или вы не хотите предоставлять основные учетные данные в этих инструментах, используйте личный маркер доступа, чтобы ограничить риск.

Можно создавать личные маркеры доступа и управлять ими одним из следующих способов:

Чтобы настроить PAT для средств, не относящихся к Майкрософт, используйте диспетчеры учетных данных Git или создайте их вручную. Мы рекомендуем ознакомиться с нашим руководством по проверке подлинности , чтобы выбрать правильный механизм проверки подлинности. Для небольших проектов, требующих менее надежного решения, личные маркеры доступа являются простой альтернативой. Если пользователи не используют диспетчер учетных данных, им придется каждый раз вводить свои учетные данные.

Создание личного маркера доступа

Примечание

Изображения, которые вы видите на веб-портале, могут отличаться от изображений, которые вы видите в этой статье. Эти различия обусловлены обновлениями, сделанными в Azure DevOps или включенными предварительными версиями функций. Мы включили функцию новой страницы диспетчера учетных записей . Основные доступные функции остаются неизменными, если не указано явно.

  1. Войдите в свою организацию (https://dev.azure.com/{yourorganization}).

  2. На домашней странице откройте параметры пользователя и выберите Личные маркеры доступа.

    Снимок экрана: выбор личных маркеров доступа.

  3. Выберите + New Token.

    Снимок экрана: выбор нового маркера.

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

    Снимок экрана: запись основных сведений о маркере.

  5. Выберите области для этого маркера для авторизации для конкретных задач.

    Например, чтобы создать маркер, позволяющий агенту сборки и выпуска проходить проверку подлинности для Azure DevOps Services, ограничьте область маркера пулами агентов (управление чтением&). Чтобы прочитать события журнала аудита, а также управлять потоками и удалять их, выберите Чтение журнала аудита, а затем щелкните Создать.

    Снимок экрана: выбранные области для PAT.

    Примечание

    Вам может быть запрещено создавать личные маркера доступа с полной областью действия. Если это так, ваш администратор Azure DevOps в Azure AD включил политику, которая ограничивает вас определенным настраиваемым набором областей. Дополнительные сведения см. в разделе Управление PAT с помощью политик или Ограничение создания полнофункционированных ПАТ. Для пользовательского определяемого PAT необходимая область для доступа к API vso.governanceуправления компонентами ( ) не может быть выбрана в пользовательском интерфейсе.

  6. Когда все будет готово, скопируйте маркер и сохраните его в безопасном месте. В целях безопасности он больше не будет отображаться.

    Снимок экрана: копирование маркера в буфер обмена.

Предупреждение

Обрабатывайте и используйте pat как пароль и храните его в секрете.

  1. Войдите на веб-портал (https://{server}:8080/tfs/).

  2. На домашней странице откройте свой профиль. Перейдите к сведениям о безопасности.

    Снимок экрана: домашняя страница, открытие профиля и кнопка

  3. Создайте личный маркер доступа.

    Снимок экрана: добавление личного маркера доступа.

  4. Присвойте токену имя. Выберите срок жизни для маркера.

    Если у вас несколько организаций, можно также выбрать организацию, в которой вы хотите использовать маркер.

    Снимок экрана: ввод сведений, включая имя и срок действия маркера.

  5. Выберите области для этого маркера для авторизации для конкретных задач.

    Например, чтобы создать маркер для проверки подлинности агента сборки и выпуска, ограничьте область маркера пулами агентов (чтение, управление).

  6. Когда все будет готово, обязательно скопируйте маркер. В целях безопасности он больше не будет отображаться. Используйте этот маркер в качестве пароля. Выберите Закрыть.

    Снимок экрана: созданный маркер.

Используйте pat в любом месте, где учетные данные пользователя необходимы для проверки подлинности в Azure DevOps.

Важно!

Для организаций, поддерживаемых Azure Active Directory, у вас есть 90 дней на вход с помощью нового pat-приложения. В противном случае он считается неактивным. Дополнительные сведения см . в статье Частота входа пользователей для условного доступа.

Уведомления

Пользователи получают два уведомления в течение жизненного цикла pat - одно после создания, а другое за семь дней до истечения срока действия.

После создания pat вы получите уведомление, аналогичное следующему примеру. Это уведомление подтверждает, что ваш ПАТ был добавлен в организацию.

Снимок экрана: уведомление о создании PAT.

На следующем рисунке показан пример семидневного уведомления до истечения срока действия pat.

Снимок экрана: уведомление о скором истечении срока действия pat.

Непредвиденное уведомление

Если вы получили непредвиденное уведомление pat, администратор или средство могли создать ПАТ от вашего имени. См. следующие примеры.

  • При подключении к репозиторию Git Azure DevOps через git.exe. он создает маркер с отображаемым именем, например "git: https://MyOrganization.visualstudio.com/ on MyMachine".
  • Когда вы или администратор настраиваете развертывание Служба приложений Azure веб-приложения, он создает маркер с отображаемым именем, например Service Hooks: : Служба приложений Azure: : Deploy web app( Развертывание веб-приложения).
  • Когда вы или администратор настраиваете веб-нагрузочное тестирование в рамках конвейера, он создает маркер с отображаемым именем, например WebAppLoadTestCDIntToken.
  • При настройке расширения обмена сообщениями для интеграции Майкрософт Teams создается маркер с отображаемым именем, например "интеграция Майкрософт Teams".

Предупреждение

Если вы считаете, что ПАТ существует по ошибке, мы рекомендуем отозвать его. Затем измените пароль. Как пользователь Azure AD, обратитесь к администратору, чтобы узнать, использовалась ли ваша организация из неизвестного источника или расположения. См. также часто задаваемые вопросы о случайном возврате pat в общедоступный репозиторий GitHub.

Использование pat

Личный маркер доступа — это ваше удостоверение, которое представляет вас при его использовании, как пароль.

Git

Для взаимодействия с Git требуется имя пользователя, которое может быть любым, кроме пустой строки. Чтобы использовать pat с обычной проверкой подлинности HTTP, используйте Base64-encode для и $MyPat, которые включены в следующий блок кода.

В PowerShell введите следующий код.

$MyPat = 'yourPAT'

$B64Pat = [Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes("`:$MyPat"))

git -c http.extraHeader="Authorization: Basic $B64Pat" clone https://dev.azure.com/yourOrgName/yourProjectName/_git/yourRepoName


Чтобы обеспечить безопасность маркера, используйте диспетчеры учетных данных, чтобы вам не нужно было вводить свои учетные данные каждый раз. Мы рекомендуем использовать диспетчер учетных данных Git. Требуется Git для Windows .

Существующие репозитории

Для существующих репозиториев, если вы уже добавили источник с помощью имени пользователя, сначала выполните следующую команду.

git remote remove origin

В противном случае выполните следующую команду.

git remote add origin https://<PAT>@<company_machineName>.visualstudio.com:/<path-to-git-repo> path to git repo = <project name>/_git/<repo_name> git push -u origin --all

Использование PAT в коде

В коде можно использовать PAT.

Если вы хотите указать PAT через заголовок HTTP, сначала преобразуйте его в строку Base64. В следующем примере показано, как преобразовать в Base64 с помощью C#.


Authorization: Basic BASE64_USERNAME_PAT_STRING

Результирующая строка может быть предоставлена в виде заголовка HTTP в следующем формате.

В следующем примере используется класс HttpClient в C#.

public static async void GetBuilds()
{
    try
    {
        var personalaccesstoken = "PATFROMWEB";

        using (HttpClient client = new HttpClient())
        {
            client.DefaultRequestHeaders.Accept.Add(
                new System.Net.Http.Headers.MediaTypeWithQualityHeaderValue("application/json"));

            client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Basic",
                Convert.ToBase64String(
                    System.Text.ASCIIEncoding.ASCII.GetBytes(
                        string.Format("{0}:{1}", "", personalaccesstoken))));

            using (HttpResponseMessage response = client.GetAsync(
                        "https://dev.azure.com/{organization}/{project}/_apis/build/builds?api-version=5.0").Result)
            {
                response.EnsureSuccessStatusCode();
                string responseBody = await response.Content.ReadAsStringAsync();
                Console.WriteLine(responseBody);
            }
        }
    }
    catch (Exception ex)
    {
        Console.WriteLine(ex.ToString());
    }
}

Совет

При использовании переменных добавьте в $ начало строки, как показано в следующем примере.

public static async void GetBuilds()
{
   try
  {
      var personalaccesstoken = "PATFROMWEB";

      using (HttpClient client = new HttpClient())
       {
           client.DefaultRequestHeaders.Accept.Add(
              new System.Net.Http.Headers.MediaTypeWithQualityHeaderValue("application/json"));

           client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Basic",
               Convert.ToBase64String(
                   System.Text.ASCIIEncoding.ASCII.GetBytes(
                       string.Format("{0}:{1}", "", personalaccesstoken))));

          using (HttpResponseMessage response = client.GetAsync(
                       $"https://dev.azure.com/{organization}/{project}/_apis/build/builds?api-version=5.0").Result)
           {
               response.EnsureSuccessStatusCode();
               string responseBody = await response.Content.ReadAsStringAsync();
               Console.WriteLine(responseBody);
           }
       }
   }
   catch (Exception ex)
   {
       Console.WriteLine(ex.ToString());
   }
}

Когда код работает, лучше всего перейти с базовой проверки подлинности на OAuth.

Дополнительные сведения и примеры использования PAT см. в следующих статьях:

Если включить обычную проверку подлинности IIS для TFS, pats будут недопустимыми. Дополнительные сведения см. в статье Использование обычной проверки подлинности IIS с локальной службой TFS.

Изменение pat

Вы можете повторно создать или расширить pat, а также изменить его область. После повторного создания предыдущий PAT больше не авторизоваться.

  1. На домашней странице откройте параметры пользователя и выберите Профиль.

    Снимок экрана: последовательность кнопок для выбора для изменения pat.

  2. В разделе Безопасность выберите Личные маркеры доступа. Выберите маркер, который требуется изменить, и нажмите кнопку Изменить.

    Снимок экрана: выделенная кнопка

  3. Измените имя маркера, организацию, к которому он применяется, срок действия маркера или область доступа, связанную с маркером, а затем нажмите кнопку Сохранить.

    Снимок экрана: сохраненный pat.

Отзыв pat

Вы можете отозвать PAT в любое время по различным причинам.

  1. На домашней странице откройте параметры пользователя и выберите Профиль.

    Снимок экрана: последовательность кнопок для выбора, Team Services, страницы предварительного просмотра и отзыва pat.

  2. В разделе Безопасность выберите Личные маркеры доступа. Выберите маркер, для которого требуется отозвать доступ, а затем нажмите кнопку Отозвать.

    Снимок экрана: выбор для отзыва одного или всех маркеров.

  3. Выберите Отозвать в диалоговом окне подтверждения.

    Снимок экрана: экран подтверждения для отзыва PAT.

Часто задаваемые вопросы

Вопрос. Что происходит с PAT, если учетная запись пользователя отключена?

О. После удаления пользователя из Azure DevOps pat становится недействительным в течение 1 часа. Если ваша организация подключена к Azure Active Directory (Azure AD), pat также становится недействительным в Azure AD, так как он принадлежит пользователю. Для поддержания работы служб рекомендуется сменить pat на другой пользователь или учетную запись службы.

Вопрос. Есть ли способ продлить pat с помощью REST API?

Ответ. Да, существует способ продления, управления и создания PAT с помощью наших API управления жизненным циклом PAT. Дополнительные сведения см. в статье Управление PAT с помощью REST API и наши вопросы и ответы.

Вопрос. Можно ли использовать базовую проверку подлинности со всеми REST API Azure DevOps?

Ответ. Нет. Вы можете использовать базовую проверку подлинности с большинством REST API Azure DevOps, но организации и профили поддерживают только OAuth. Дополнительные сведения см. в статье Управление PAT с помощью REST API.

Вопрос. Что произойдет, если я случайно проверю свой PAT в общедоступном репозитории на GitHub?

О. Azure DevOps проверяет наличие PAT, которые были возвращены в общедоступные репозитории на GitHub. Когда мы обнаруживаем утечку маркера, мы немедленно отправляем владельцу маркера подробное уведомление по электронной почте и регистрируем событие в журнал аудита вашей организации Azure DevOps. Мы рекомендуем затронутым пользователям немедленно устранить последствия, сменив или отменив утечку PAT.

Существует политика для управления утечкой PAT! Дополнительные сведения см. в статье Автоматическое отмена утечки PAT.

Вопрос. Можно ли использовать личный маркер доступа в качестве apiKey для публикации пакетов NuGet в веб-канале Azure Artifacts с помощью командной строки dotnet/nuget.exe?

Ответ. Нет. Azure Artifacts не поддерживает передачу личного маркера доступа в качестве ApiKey. При использовании локальной среды разработки рекомендуется установить поставщик учетных данных Azure Artifacts для проверки подлинности с помощью Azure Artifacts. Дополнительные сведения см. в следующих примерах: dotnet,NuGet.exe. Если вы хотите опубликовать пакеты с помощью Azure Pipelines, используйте задачу Проверка подлинности NuGet для проверки подлинности в примере веб-канала.