Use Enterprise Security Package in HDInsight (Корпоративный пакет безопасности для HDInsight)

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

Многие организации перешли на модель, в которой команды ИТ-специалистов управляют кластерами, а команды из нескольких приложений совместно используют кластеры. Таким крупным предприятиям требуется многопользовательский доступ к кластерам в Azure HDInsight.

HDInsight использует наиболее популярный поставщик удостоверений — управляемую службу Active Directory. Интеграция HDInsight с доменными службами Microsoft Entra позволяет получить доступ к кластерам с помощью учетных данных домена.

Виртуальные машины в HDInsight присоединены к указанному домену. Все службы, запущенные в HDInsight (Apache Ambari, сервер Apache Hive, Apache Ranger, сервер Apache Spark Thrift и т. п.), согласованно работают для пользователя, прошедшего поддержку подлинности. Администраторы могут настраивать строгие политики авторизации на основе Apache Ranger, чтобы применять управление доступом на основе ролей для ресурсов в кластере.

Интеграция HDInsight с Active Directory

Apache Hadoop с открытым кодом полагается на протокол Kerberos для аутентификации и обеспечения безопасности. Поэтому узлы кластера HDInsight с корпоративным пакетом безопасности (ESP) присоединяются к домену, управляемому доменными службами Microsoft Entra. Для включенных в кластер компонентов Hadoop настраиваются параметры безопасности Kerberos.

Указанные ниже действия создаются автоматически.

  • Субъект-служба для каждого компонента Hadoop.
  • Соответствующий субъект компьютера для каждого компьютера, присоединенного к домену.
  • Подразделение (OU) для каждого кластера для хранения этих субъектов службы и компьютера.

Кратко перечислим, что вам нужно создать в сетевом окружении:

  • Домен Active Directory (управляемый доменными службами Microsoft Entra). Имя домена должно содержать не более 39 символов для работы с Azure HDInsight.
  • Защищенный протокол LDAP (LDAPS), включенный в доменных службах Microsoft Entra.
  • Правильное сетевое подключение из виртуальной сети HDInsight к виртуальной сети доменных служб Microsoft Entra при выборе отдельных виртуальных сетей. Виртуальная машина в виртуальной сети HDInsight должна иметь линию видимости для доменных служб Microsoft Entra через пиринг виртуальной сети. Если доменные службы HDInsight и Microsoft Entra развертываются в одной виртуальной сети, подключение автоматически предоставляется, а дальнейшие действия не требуются.

Настройка разных контроллеров домена

В настоящее время HDInsight поддерживает только доменные службы Microsoft Entra в качестве основного контроллера домена, который кластер использует для обмена данными Kerberos. Но другие сложные настройки Active Directory возможны, если такая настройка приводит к включению доменных служб Microsoft Entra для доступа HDInsight.

Доменные службы Microsoft Entra

Доменные службы Microsoft Entra предоставляют управляемый домен, который полностью совместим с Windows Server Active Directory. Корпорация Майкрософт управляет доменом, применяет к нему исправления и осуществляет его мониторинг в конфигурации высокой доступности. Вы можете развернуть свой кластер, не беспокоясь о поддержке контроллеров домена.

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

Дополнительные сведения см. в разделе "Настройка кластеров HDInsight с помощью ESP" с помощью доменных служб Microsoft Entra.

Локальная служба Active Directory или служба Active Directory на виртуальных машинах IaaS

Если у вас есть локальная служба Active Directory экземпляр или более сложные настройки Active Directory для вашего домена, вы можете синхронизировать эти удостоверения с идентификатором Microsoft Entra Id с помощью Microsoft Entra Connect. Затем вы можете включить доменные службы Microsoft Entra в этом клиенте Active Directory.

Так как Kerberos использует хэши паролей, необходимо включить синхронизацию хэша паролей в доменных службах Microsoft Entra.

Если вы используете федерацию с помощью служб федерации Active Directory (ADFS), нужно включить синхронизацию хэша пароля (рекомендуемую настройку см. здесь). Это также помогает при аварийном восстановлении в случае сбоя инфраструктуры ADFS и защищает от утечки учетных данных. Дополнительные сведения см. в разделе "Включить синхронизацию хэша паролей" с microsoft Entra Connect Sync.

При использовании локальная служба Active Directory или Active Directory на виртуальных машинах IaaS только без идентификатора Microsoft Entra и доменных служб Microsoft Entra не поддерживается конфигурация для кластеров HDInsight с ESP.

Примечание.

Модули Azure AD и MSOnline PowerShell устарели с 30 марта 2024 г. Дополнительные сведения см. в обновлении об отмене. После этой даты поддержка этих модулей ограничена поддержкой миграции в пакет SDK Для Microsoft Graph PowerShell и исправления безопасности. Устаревшие модули будут продолжать функционировать до 30 марта 2025 года.

Рекомендуется перенести в Microsoft Graph PowerShell для взаимодействия с идентификатором Microsoft Entra (ранее — Azure AD). Часто задаваемые вопросы о миграции см. в разделе "Вопросы и ответы о миграции". Примечание. Версии 1.0.x MSOnline могут возникнуть сбоем после 30 июня 2024 г.

Если вы используете федерацию и хэши паролей синхронизируются правильно, но вы получаете сбои проверки подлинности, проверьте, включена ли проверка подлинности в облаке для субъекта-службы PowerShell. В противном случае необходимо задать политику обнаружения домашней области (HRD) для клиента Microsoft Entra. Чтобы проверить и установить политику HRD, выполните следующие действия.

  1. Установите предварительную версию модуля Azure AD PowerShell.

    Install-Module AzureAD
    
  2. Подключитесь с помощью учетных данных администратора (администратора клиента).

    Connect-AzureAD
    
  3. Проверьте, была ли уже создана субъект-служба Microsoft Azure PowerShell.

    Get-AzureADServicePrincipal -SearchString "Microsoft Azure PowerShell"
    
  4. Если нет, то создайте субъект-службу.

    $powershellSPN = New-AzureADServicePrincipal -AppId 1950a258-227b-4e31-a9cf-717495945fc2
    
  5. Создайте и примените политику к этому субъекту-службе.

     # Determine whether policy exists
     Get-AzureADPolicy | Where {$_.DisplayName -eq "EnableDirectAuth"}
    
     # Create if not exists
     $policy = New-AzureADPolicy `
         -Definition @('{"HomeRealmDiscoveryPolicy":{"AllowCloudPasswordValidation":true}}') `
         -DisplayName "EnableDirectAuth" `
         -Type "HomeRealmDiscoveryPolicy"
    
     # Determine whether a policy for the service principal exist
     Get-AzureADServicePrincipalPolicy `
         -Id $powershellSPN.ObjectId
    
     # Add a service principal policy if not exist
     Add-AzureADServicePrincipalPolicy `
         -Id $powershellSPN.ObjectId `
         -refObjectID $policy.ID
    

Следующие шаги