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

Субъекты-службы для CI/CD

  • Статья

В этой статье описывается использование субъектов-служб для CI/CD в Azure Databricks. Субъект-служба — это удостоверение, созданное для использования с автоматизированными инструментами и приложениями, включая следующие:

В качестве рекомендации по обеспечению безопасности Databricks рекомендует использовать субъект-службу и его токен вместо пользователя Azure Databricks или личного маркера доступа Databricks для пользователя рабочей области, чтобы предоставить пользователям ci/CD доступ к ресурсам Azure Databricks. Такой подход отличается следующими преимуществами.

  • Вы можете предоставить и ограничить доступ к ресурсам Azure Databricks для субъекта-службы независимо от пользователя. Например, это позволяет запретить субъекту-службе выступать в качестве администратора в рабочей области Azure Databricks, позволяя другим пользователям в рабочей области продолжать выступать в качестве администраторов.
  • Пользователи могут не предоставлять платформам CI/CD доступ к своим маркерам доступа.
  • Вы можете временно отключить или окончательно удалить субъект-службу, не влияя на других пользователей. Например, это позволяет приостановить или удалить доступ из субъекта-службы, который вы подозреваете, используется злоумышленником.
  • Если пользователь покидает организацию, его можно удалить, не влияя на субъект-службу.

Чтобы предоставить платформе CI/CD доступ к рабочей области Azure Databricks, выполните указанные ниже действия.

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

Требования

  • Маркер OAuth Azure Databricks или маркер идентификатора Microsoft Entra для управляемого субъекта-службы Azure Databricks или управляемого субъекта-службы Идентификатора Microsoft Entra ID. Чтобы создать управляемый субъект-службу Azure Databricks или управляемый субъект-службу идентификатора Microsoft Entra ID и его токен OAuth Azure Databricks или маркер идентификатора Microsoft Entra, см. статью "Управление субъектами-службами".
  • Учетная запись с поставщиком GIT.

Настройка GitHub Actions

Для GitHub Actions требуется доступ к рабочей области Azure Databricks. Если вы хотите использовать папки Azure Databricks Git, ваша рабочая область также должна иметь доступ к GitHub.

Чтобы включить GitHub Actions для доступа к рабочей области Azure Databricks, необходимо предоставить сведения об управляемом субъекте-службе Azure Databricks или управляемом субъекте-службе Microsoft Entra ID в GitHub Actions. Это может включать такие сведения, как идентификатор приложения (клиента), идентификатор каталога (клиента) для управляемого субъекта-службы Microsoft Entra ID, секрет клиента управляемого субъекта-службы Azure Databricks или секрет клиента управляемого субъекта-службы Microsoft Entra ID или access_token значение для управляемого субъекта-службы Azure Databricks в зависимости от требований GitHub Action. Дополнительные сведения см. в разделе "Управление субъектами-службами " и документацией по GitHub Action.

Если вы также хотите включить рабочую область Azure Databricks для доступа к GitHub при использовании папок Azure Databricks Git, необходимо добавить личный маркер доступа GitHub для пользователя компьютера GitHub в рабочую область.

Предоставление сведений о субъекте-службе в GitHub Actions

В этом разделе описано, как настроить в GitHub Actions доступ к рабочей области Azure Databricks.

В качестве рекомендации по обеспечению безопасности Databricks рекомендует не вводить сведения о субъекте-службе непосредственно в текст файла GitHub Actions. Эти сведения следует предоставлять в GitHub Actions с помощью зашифрованных секретов GitHub.

GitHub Actions, например те, которые Databricks перечисляют в непрерывной интеграции и доставке с помощью GitHub Actions, используют различные зашифрованные секреты GitHub, такие как:

  • DATABRICKS_HOST содержит значение https://, за которым следует имя экземпляра рабочей области, например adb-1234567890123456.7.azuredatabricks.net.
  • AZURE_CREDENTIALS— это документ JSON, представляющий выходные данные запуска Azure CLI для получения сведений об управляемом субъекте-службе Идентификатора Microsoft Entra. Дополнительные сведения см. в документации по конкретному действию GitHub Actions.
  • AZURE_SP_APPLICATION_ID— значение идентификатора приложения (клиента) для управляемого субъекта-службы Microsoft Entra ID.
  • AZURE_SP_TENANT_ID— это значение идентификатора каталога (клиента) для управляемого субъекта-службы Microsoft Entra ID.
  • AZURE_SP_CLIENT_SECRET— значение значения секрета клиента для управляемого субъекта-службы Идентификатора Microsoft Entra.

Дополнительные сведения о том, какие зашифрованные секреты GitHub требуются для действия GitHub, см. в статье "Управление субъектами-службами " и документацией по этой GitHub Action.

Чтобы добавить нужные зашифрованные секреты GitHub в репозиторий GitHub, воспользуйтесь разделом Создание зашифрованных секретов для репозитория в документации по GitHub. Еще несколько подходов к добавлению секретов репозитория GitHub есть в разделе Зашифрованные секреты документации GitHub.

Добавление личного маркера доступа GitHub для пользователя компьютера GitHub в рабочую область Azure Databricks

В этом разделе описывается, как включить рабочую область Azure Databricks для доступа к GitHub с помощью папок Azure Databricks Git. Это необязательная задача в сценариях CI/CD.

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

  1. Создайте пользователя компьютера GitHub, если у вас его еще нет. Пользователь компьютера GitHub — это личная учетная запись GitHub, которую можно использовать для автоматизации действий на GitHub, отличная от вашей личной учетной записи GitHub. Создайте отдельную учетную запись GitHub для использования в качестве пользователя компьютера GitHub, если у вас ее еще нет.

    Примечание.

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

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

  2. Предоставьте пользователю компьютера GitHub доступ к репозиторию GitHub. Ознакомьтесь с разделом Приглашение команды или человека в документации GitHub. Чтобы принять это приглашение, вам придется выйти из личной учетной записи GitHub и войти в систему от имени пользователя компьютера GitHub.

  3. Войдите в GitHub от имени пользователя компьютера и создайте личный маркер доступа GitHub для этого пользователя компьютера. См. раздел Создание личного маркера доступа в документации GitHub. Обязательно предоставьте GitHub доступ к репозиторию с личным маркером доступа.

  4. Соберите маркер идентификатора Microsoft Entra для субъекта-службы, имени пользователя компьютера GitHub и добавьте учетные данные поставщика Git в рабочую область Azure Databricks.

Настройка Azure Pipelines

Azure Pipelines требуется доступ к рабочей области Azure Databricks. Если вы также хотите использовать папки Azure Databricks Git, рабочая область должна иметь доступ к Azure Pipelines.

В файлах конвейера YAML в Azure Pipelines используются переменные среды для доступа к рабочей области Azure Databricks. К переменным среды относятся такие переменные, как:

  • DATABRICKS_HOST содержит значение https://, за которым следует имя экземпляра рабочей области, например adb-1234567890123456.7.azuredatabricks.net.
  • DATABRICKS_TOKEN— значение token_value значения, скопированного после создания маркера идентификатора Microsoft Entra для управляемого субъекта-службы Microsoft Entra ID.

Сведения о добавлении этих переменных среды в конвейер Azure см. в статьях Использование секретов типа "ключ-значение" Azure в Azure Pipelines и Установка переменных секретов в документации Azure.

См. также следующий блог Databricks:

Необязательно для сценариев CI/CD: если в рабочей области используются папки Azure Databricks Git, и вы хотите включить рабочую область для доступа к Azure Pipelines, соберите:

  • Маркер идентификатора Microsoft Entra для субъекта-службы
  • имя пользователя Azure Pipelines.

Затем добавьте учетные данные поставщика Git в рабочую область Azure Databricks.

Настройка GitLab CI/CD

GitLab CI/CD требуется доступ к рабочей области Azure Databricks. Если вы также хотите использовать папки Azure Databricks Git, рабочая область должна иметь доступ к GitLab CI/CD.

Для доступа к рабочей области Azure Databricks в файлах .gitlab-ci.yml GitLab CI/CD, например входящих в состав базового шаблона Python в dbx, применяются пользовательские переменные CI/CD, такие как:

  • DATABRICKS_HOST содержит значение https://, за которым следует имя экземпляра рабочей области, например adb-1234567890123456.7.azuredatabricks.net.
  • DATABRICKS_TOKEN— значение token_value значения, скопированного после создания маркера идентификатора Microsoft Entra для субъекта-службы.

Чтобы добавить эти пользовательские переменные в проект GitLab CI/CD, обратитесь к статье Добавление переменной CI/CD в проект в документации по GitLab CI/CD.

Если в рабочей области используются папки Databricks Git и вы хотите включить рабочую область для доступа к CI/CD GitLab, соберите следующее:

  • Маркер идентификатора Microsoft Entra для субъекта-службы
  • имя пользователя GitLab CI/CD.

Затем добавьте учетные данные поставщика Git в рабочую область Azure Databricks.

Добавление учетных данных поставщика Git в рабочую область Azure Databricks

В этом разделе описывается, как включить рабочую область Azure Databricks для доступа к поставщику Git для папок Azure Databricks Git. В сценариях CI/CD это необязательное действие. Например, может потребоваться, чтобы поставщик Git мог получить доступ к рабочей области Azure Databricks, но вам не нужно использовать папки Azure Databricks Git в рабочей области с поставщиком Git. В таком случае пропустите этот раздел.

Прежде чем начать, получите следующие данные и средства:

  • Маркер идентификатора Microsoft Entra для субъекта-службы.
  • имя пользователя, связанное с поставщиком GIT;
  • маркер доступа, связанный с пользователем для поставщика GIT.

Примечание.

Для Azure Pipelines см. статью Использование личных маркеров доступа на веб-сайте Azure.

  • Databricks CLI версии 0.205 или более поздней. См. сведения о интерфейсе командной строки Databricks?. Но вы не можете использовать пользовательский интерфейс Azure Databricks.
  • Профиль конфигурации Azure Databricks в .databrickscfg файле с полями профиля правильно задан для связанного host URL-адреса Azure Databricks для рабочей области, например https://adb-1234567890123456.7.azuredatabricks.netи token представляющего маркер идентификатора Microsoft Entra для субъекта-службы. (Не используйте личный маркер доступа Databricks для пользователя рабочей области.) См. проверку подлинности маркера личного доступа Azure Databricks.

Используйте интерфейс командной строки Databricks, чтобы выполнить следующую команду:

databricks git-credentials create <git-provider-short-name> --git-username <git-provider-user-name> --personal-access-token <git-provider-access-token> -p <profile-name>
  • Используйте одно из следующих вариантов <git-provider-short-name>:
    • Для GitHub используйте GitHub.
    • Для Azure Pipelines используйте AzureDevOpsServices.
    • Для GitLab CI/CD используйте GitLab.
  • Замените <git-provider-user-name> имя пользователя, связанное с поставщиком Git.
  • Замените <git-provider-access-token> маркер доступа, связанный с пользователем для поставщика Git.
  • Замените <profile-name> именем профиля конфигурации Azure Databricks в .databrickscfg файле.

Совет

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

databricks git-credentials list -p <profile-name>

databricks git-credentials get <credential-id> -p <profile-name>