Поделиться через


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

$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 из хранилища ключей. Сервис автоматически обменивает ваш токен Azure на токен Azure DevOps в режиме выполнения.

В этом примере показана сокращенная версия 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 во время настройки с помощью существующей функции секретов.

  1. Создайте субъект-службу в Azure Active Directory (Azure AD) и назначьте ей необходимые роли для ресурсов, которые вы хотите использовать.

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

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

    $ az ad sp create-for-rbac -n DevBoxCustomizationsTest
    
    {
      "appId": "...",
      "displayName": "DevBoxCustomizationsTest",
      "password": "...",
      "tenant": "..."
    }
    
  2. Сохраните пароль, возвращенный выше, в секрете Key Vault, как показано ниже. https://mykeyvault.vault.azure.net/secrets/password

  3. В Key Vault предоставьте удостоверению проекта роль пользователя секретов Key Vault .

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

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

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

  1. Устанавливает Azure CLI с помощью диспетчера пакетов winget.

  2. Запускает скрипт 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, выполните приведенные действия.

  1. Войдите в организацию Azure DevOps и откройте параметры организации.

  2. В меню выберите "Пользователи".

  3. На странице "Пользователи" выберите "Добавить пользователей".

  4. В диалоговом окне "Добавление новых пользователей" введите следующие сведения:

    Снимок экрана: диалоговое окно

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

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