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, выполните следующие действия.
Установите предварительную версию модуля Azure AD PowerShell.
Install-Module AzureAD
Подключитесь с помощью учетных данных администратора (администратора клиента).
Connect-AzureAD
Проверьте, была ли уже создана субъект-служба Microsoft Azure PowerShell.
Get-AzureADServicePrincipal -SearchString "Microsoft Azure PowerShell"
Если нет, то создайте субъект-службу.
$powershellSPN = New-AzureADServicePrincipal -AppId 1950a258-227b-4e31-a9cf-717495945fc2
Создайте и примените политику к этому субъекту-службе.
# 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