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

Субъекты-службы для 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

Для 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 ID. Дополнительные сведения см. в документации по конкретному действию 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 ID для учетной записи службы, имя пользователя GitHub, а затем см. раздел Использование учетной записи службы с папками Databricks Git.

Настройка 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.

Затем см. раздел "Использование служебного субъекта с папками Databricks Git".

Настройте 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.

Затем см. раздел "Использование служебного субъекта с папками Databricks Git".