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

Принципы службы для CI/CD

В этой статье описывается использование служебных принципов для CI/CD в Azure Databricks. Учетная запись службы — это удостоверение, созданное для использования с автоматизированными инструментами и приложениями, в том числе:

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

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

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

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

Требования

  • Маркер OAuth Azure Databricks или токен Microsoft Entra ID для управляемого субъекта-службы Azure Databricks или управляемого субъекта-службы Microsoft Entra ID. Сведения о создании управляемого субъекта-службы Azure Databricks или управляемого субъекта-службы Microsoft Entra ID и токена OAuth Azure Databricks или токена Microsoft Entra ID см. в разделе «Субъекты-службы».
  • Учетная запись с поставщиком GIT.

Настройте действия GitHub

GitHub Actions должен иметь доступ к рабочей области Azure Databricks. Если вы хотите использовать папки Git в Azure Databricks, ваша рабочая область также должна иметь доступ к 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 при использовании папок Git в Azure Databricks, необходимо добавить личный токен доступа 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.
  • AZURE_SP_APPLICATION_ID— значение идентификатора приложения (клиента) для управляемого субъекта-службы Microsoft Entra ID.
  • AZURE_SP_TENANT_ID— это значение идентификатора каталога (клиента) для управляемого субъекта-службы Microsoft Entra ID.
  • AZURE_SP_CLIENT_SECRET— это значение поля Value секрета клиента для управляемого служебного субъекта Microsoft Entra ID.

Дополнительные сведения о том, какие зашифрованные секреты GitHub необходимы для GitHub Action, см. в разделе Service principals и в документации по этому 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 и его личными токенами доступа в вашей организации.

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

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

  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 ID для управляемого служебного субъекта Microsoft Entra ID.

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

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

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

  • Идентификационный токен Microsoft Entra для служебного принципала
  • ваше имя пользователя в Azure Pipelines.

Затем см. раздел (Использование service principal с папками Databricks Git).

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

GitLab CI/CD должен иметь доступ к рабочей области Azure Databricks. Если вы также хотите использовать папки Git в Azure Databricks, рабочая область должна иметь доступ к 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 ID для service principal.

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

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

  • Идентификационный токен Microsoft Entra для служебного принципала
  • ваше имя пользователя GitLab CI/CD.

Затем см. раздел (Использование service principal с папками Databricks Git).