Безопасное подключение к ресурсам Azure или клонирование частных репозиториев

При доступе к ресурсам, таким как репозитории или ресурсы Azure во время настройки, можно безопасно пройти проверку подлинности. Чтобы избежать хранения секретных значений в файлах настройки и системе управления версиями, ссылайтесь на секреты Azure Key Vault в файлах настройки. Используйте служебные принципы для проверки подлинности в Azure и безопасного доступа к ресурсам. В этой статье объясняется, как безопасно управлять ресурсами и получать доступ к ним во время настройки поля разработки.

Предпосылки

Центр разработки и проект, настроенный для Dev Box. Если у вас его нет, см. статью "Настройка Microsoft Dev Box".
Разрешение на создание поля разработки по крайней мере в одном проекте. Сведения о настройке и доступе см. в разделе "Создание поля разработки".
Разрешения, необходимые для настройки настроек, доступа к Key Vault и каталогов. См. раздел "Разрешения" для настроек.
Хранилище ключей Azure, содержащее секреты, которые вы хотите использовать.
(Примеры субъекта-службы) Azure CLI установлен и вошел в систему, а также разрешение на создание субъектов-служб. Подробнее см. статью Установка Azure CLI.

Вопросы безопасности

Интеграция Azure Key Vault помогает избежать хранения секретных значений в файлах настройки и системе управления версиями. Однако Dev Box разрешает заполнители секретных данных во время настройки. В зависимости от того, как выполняется задача и что она записывает в выходные данные, разрешенные значения секретов могут отображаться в выходных данных или журналах задач.

Это важно

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

Чтобы уменьшить вероятность воздействия, выполните следующие действия.

По возможности предпочитайте подходы на основе удостоверений или обмена токенами (например, обмен токенами Azure DevOps) вместо долгоживущих личных маркеров доступа (PAT).
Не печатайте конфиденциальные данные в вывод. Избегайте подробных или отладочных режимов, которые могут повторять учетные данные, URL-адреса или заголовки.
Избегайте внедрения секретов непосредственно в командные строки или URL-адреса. Если секрет отображается в журналах, отмените или измените его и обновите хранилище ключей.

Использование секретов хранилища ключей в файлах настройки

Используйте секреты из Azure Key Vault в настройках YAML для клонирования частных репозиториев или выполнения задач, требующих маркера доступа. Например, в файле настройки используйте личный маркер доступа (PAT), хранящийся в Azure Key Vault, для доступа к частному репозиторию.

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

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

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

Настройка доступа к хранилищу ключей для настроек

Центр разработки должен получить доступ к хранилищу ключей. Чтобы настроить секреты в хранилище ключей для использования в вашей команде или в пользовательских настройках, убедитесь, что у управляемого удостоверения проекта Dev Center есть роль пользователя секретов хранилища ключей Key Vault в вашем хранилище ключей.

Если политиками вашей организации требуется оставить ваше хранилище ключей закрытым от открытого Интернета, вы можете создать правило брандмауэра для отключения или ограничения общедоступного доступа. Необходимо разрешить доверенным службам Майкрософт обойти брандмауэр, так как Центр разработки не поддерживает теги служб. Хранилища ключей с частными подключениями или частными каналами связи в текущем сценарии не поддерживаются.

На следующем снимке экрана показано, как разрешить доверенным службам Майкрософт обойти брандмауэр в параметрах Azure Key Vault.

Дополнительные сведения о том, как разрешить доверенным службам Майкрософт обойти брандмауэр, см. в статье "Настройка параметров сети Azure Key Vault".

Дополнительная конфигурация для пользовательских настроек

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

Убедитесь, что управляемое удостоверение в проекте Центра разработки имеет роли Key Vault Reader и Key Vault Secrets User в вашем хранилище ключей.
Предоставьте роль пользователя Секретов Key Vault для секрета каждому пользователю или группе, которым он нужен во время настройки поля разработки, включая управляемое удостоверение Центра разработки, учетные записи администраторов и любые другие необходимые пользователи или группы.

Пример настройки группы

Этот синтаксис использует секрет хранилища ключей (PAT) в файле определения изображения. Это KEY_VAULT_SECRET_URI идентификатор секрета (URI) для секрета в хранилище ключей.

Подсказка

Используйте безверсийный идентификатор секрета, чтобы Dev Box мог получить последнюю версию секрета. Пример см. в руководстве "Секретный идентификатор" в разделе "Добавление каталогов и управление ими в Microsoft Dev Box".

$schema: "<SCHEMA_VERSION>"
name: "<IMAGE_DEFINITION_NAME>"
image: "<BASE_IMAGE>"
description: "<DESCRIPTION>"

tasks:
  - name: <TASK_NAME>
    description: <TASK_DESCRIPTION>
    parameters:
      repositoryUrl: <REPOSITORY_URL>
      directory: <DIRECTORY_PATH>
      pat: "{{<KEY_VAULT_SECRET_URI>}}"

В этом примере используется git-clone задача:

$schema: "1.0"
name: "example-image-definition"
image: microsoftvisualstudio_visualstudioplustools_vs-2022-ent-general-win11-m365-gen2
description: "Clones a public example Git repository"

tasks:
  - name: git-clone
    description: Clone this repository into C:\workspaces
    parameters:
      repositoryUrl: https://github.com/example-org/example-repo.git
      directory: C:\workspaces
      pat: "{{https://contoso-vault.vault.azure.net/secrets/github-pat}}"

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

$schema: "1.0" 
name: "example-image-definition"
image: microsoftvisualstudio_visualstudioplustools_vs-2022-ent-general-win11-m365-gen2
description: "Clones a public example Git repository"

tasks:  
- name: git-clone
    description: Clone this repository into C:\Workspaces 
    parameters: 
    command: MyCommand –MyParam "{{KEY_VAULT_SECRET_URI}}"

Пример настройки пользователей

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

В этом примере показана сокращенная версия ADO ({{ado://...}}). Служба обменивает ваш маркер Azure на маркер Azure DevOps во время выполнения, поэтому вам не нужно хранить PAT в Key Vault.

$schema: "1.0"
tasks:
  - name: git-clone
    description: Clone this repository into C:\workspaces
    parameters:
      repositoryUrl: https://dev.azure.com/example-org/MyProject/_git/example-repo
      directory: C:\workspaces
      pat: '{{ado://example-org}}'

Расширение Dev Box Visual Studio Code и интерфейс командной строки Dev Box не поддерживают подгрузку секретов в процессе тестирования на внутреннем цикле для кастомизаций.

Аутентификация в ресурсах Azure с помощью учетных записей службы

Используя служебные принципы, вы можете аутентифицироваться для ресурсов Azure без использования учетных данных пользователя. Создайте служебный принципал, назначьте необходимые роли и используйте его для аутентификации в задаче настройки. Обновите его пароль из Key Vault при настройке с использованием существующей функции секретов.

Создайте служебный субъект в Microsoft Entra ID и назначьте ему необходимые роли для ресурсов, которые вы хотите использовать.

Выходные данные — это объект JSON, содержащий идентификатор приложения субъекта-службы, displayName, пароль и клиент, которые используются для проверки подлинности и авторизации в сценариях автоматизации Azure.

Пример: выходные данные CLI при создании служебного принципала. Сохраните возвращенный пароль в Key Vault и предоставьте идентификатору проекта центра разработки роль пользователя секретов Key Vault, чтобы настройка загрузила секрет во время выполнения программы.
```
$ az ad sp create-for-rbac -n DevBoxCustomizationsTest

{
  "appId": "...",
  "displayName": "DevBoxCustomizationsTest",
  "password": "...",
  "tenant": "..."
}
```
Сохраните пароль, возвращенный на предыдущем шаге, в секрете Key Vault, как показано ниже. https://mykeyvault.vault.azure.net/secrets/password
В Key Vault предоставьте удостоверению проекта роль пользователя секретов Key Vault .

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

Пример. Скачивание файла из службы хранилища Azure

В следующем примере показано, как скачать файл из учетной записи хранения. Фрагмент КОДА YAML определяет настройку Dev Box, которая выполняет две основные задачи:

Устанавливает Azure CLI с помощью диспетчера пакетов winget.
Запускает скрипт PowerShell, который:

Выполняет проверку подлинности в Azure с помощью сервисного принципала, при этом пароль получен из Azure Key Vault.
Загружает объект blob (файл) из учетной записи хранения Azure, используя аутентифицированный сеанс.

Пример настройки, которая извлекает пароль субъекта службы из Key Vault и использует его для проверки подлинности и скачивания объекта BLOB из службы хранилища Azure. Сохраните пароль сервисного субъекта в Key Vault и убедитесь, что идентификатор проекта имеет роль пользователя секретов Key Vault.

$schema: "1.0"
name: "devbox-customization"
tasks:
  - name: ~/winget
    parameters:
      package: Microsoft.AzureCLI
  - name: ~/powershell
    parameters:
      command: |
        az login --service-principal `
          --username <appId> `
          --password {{https://mykeyvault.vault.azure.net/secrets/password}} `
          --tenant <tenantId>
        az storage blob download `
          --account-name <storage_account_name> `
          --container-name <container_name> `
          --name <blob_name> `
          --file <local_file_path> `
          --auth-mode login

Эта настройка позволяет автоматизировать безопасное использование ресурсов Azure во время подготовки Dev Box без предоставления учетных данных в скрипте.

Пример. Скачивание артефакта из Azure DevOps

Скачайте артефакты сборки из Azure DevOps (ADO) с использованием сервисного принципала для аутентификации. Добавьте идентификатор приложения служебного принципала (appId) как пользователя в организацию Azure DevOps, а затем назначьте принципала группе Читатели. На этом этапе предоставляются необходимые разрешения для использования артефактов сборки.

После настройки этих шагов используйте учетные данные сервисного принципала для аутентификации и безопасного скачивания артефактов из Azure DevOps в задачах настройки.

Добавление субъекта-службы в организацию Azure DevOps

Чтобы добавить субъект-службу в организацию Azure DevOps, выполните приведенные действия.

Войдите в организацию Azure DevOps и откройте параметры организации.
В меню выберите "Пользователи".
На странице "Пользователи" выберите "Добавить пользователей".
В диалоговом окне "Добавление новых пользователей" введите следующие сведения:
- Пользователи: введите идентификатор приложения (appId) как адрес электронной почты пользователя.
- Уровень доступа: выберите "Базовый".
- Добавьте в проект: выберите проект, в который нужно добавить субъект-службу.
- Группы Azure DevOps: назначьте служебный принципал группе Читателей.
Завершите процесс, чтобы предоставить необходимые разрешения.

Дополнительные сведения о добавлении пользователей в организации DevOps см. в статье «Добавление пользователей в организацию и управление доступом».

Узнайте, как задать и получить секрет из Azure Key Vault с помощью портала Azure.
Узнайте, как добавлять каталоги и управлять ими в Microsoft Dev Box.
Узнайте, как использовать учётные записи служб и управляемые удостоверения в Azure DevOps.

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2026-02-27