Развертывание кластеров больших данных SQL Server в режиме AD в службах Azure Kubernetes (AKS)

Кластеры больших данных SQL Server поддерживают режим развертывания Active Directory (AD) для управления удостоверениями и доступом (IAM). Служба IAM для Azure Kubernetes (AKS) была сложной, так как отраслевые стандартные протоколы, такие как OAuth 2.0 и OpenID Connect, которые широко поддерживаются платформой удостоверений Майкрософт, не поддерживаются SQL Server.

В этой статье объясняется, как развернуть кластер больших данных в режиме AD при развертывании в службе Azure Kubernetes (AKS).

Architecture topologies

Доменные службы Active Directory (AD DS) выполняются на виртуальной машине Azure так же, как и во многих локальных экземплярах. После продвижения новых контроллеров домена в Azure задайте первичные и вторичные DNS-серверы для виртуальной сети, понижение числа локальных DNS-серверов будет понижено до третичного или более поздней версии. Проверка подлинности AD позволяет клиентам, присоединенным к домену, в Linux проходить проверку подлинности в SQL Server с помощью учетных данных домена и протокола Kerberos.

Существует несколько способов развертывания кластера больших данных в режиме AD в AKS. В этой статье представлено два метода, которые проще реализовать и интегрировать с существующими архитектурами корпоративного уровня:

• Расширьте локальный домен Active Directory в Azure. Этот метод позволяет среде Active Directory предоставлять распределенные службы проверки подлинности с помощью доменных служб Active Directory (AD DS) в Azure. Вы реплицируете локальные доменные службы Active Directory (AD DS) для уменьшения задержки, вызванной отправкой запросов проверки подлинности из облака обратно в локальные доменные службы AD DS. Типичным вариантом использования этого решения является размещение приложения частично в локальной среде и частично в Azure, а запросы проверки подлинности — обратно и вперед.

• Расширьте лес ресурсов доменных служб Active Directory (AD DS) в Azure. В этой архитектуре создается новый домен в Azure, доверенный локальным лесом AD. Эта архитектура показывает односторонняя доверие из домена в Azure в локальный лес.

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

На следующем изображении представлена типичная архитектура:

Recommendations

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

Networking recommendations

Для подключения локальной среды к Azure можно использовать несколько ключевых компонентов:

• VPN-шлюз Azure: VPN-шлюз — это определенный тип шлюза виртуальной сети, который используется для отправки зашифрованного трафика между виртуальной сетью Azure и локальным расположением через общедоступный Интернет. Вы будете использовать шлюз виртуальной сети Azure и локальный шлюз виртуальной сети. Дополнительные сведения о настройке см. в разделе "Что такое VPN-шлюз".
• Azure ExpressRoute: подключения ExpressRoute не проходят через общедоступный Интернет и обеспечивают более высокую безопасность, надежность и скорость с более низкой задержкой, чем типичные подключения через Интернет. Выбор варианта подключения влияет на уровень задержки, производительности и соглашения об уровне обслуживания решения в зависимости от номеров SKU. Дополнительные сведения см. в разделе "Сведения о шлюзах виртуальной сети ExpressRoute".

Большинство клиентов используют прыжок или Бастион Azure для доступа к другой инфраструктуре Azure. Приватный канал Azure позволяет безопасно получить доступ к службам PaaS Azure, включая AKS в этом сценарии, а также другие размещенные в Azure службы через частную конечную точку в виртуальной сети. Трафик между виртуальной сетью и службой проходит по магистральной сети Майкрософт, устраняя уязвимость к общедоступному Интернету. Кроме того, вы можете создать в своей виртуальной сети собственную службу "Приватный канал" и предоставлять ее клиентам в частном порядке.

Рекомендации Active Directory и Azure

Локальные службы AD DS хранят сведения о учетных записях пользователей и позволяют другим авторизованным пользователям в той же сети получать доступ к этой информации путем проверки подлинности удостоверений, связанных с пользователями, компьютерами, приложениями или другими ресурсами, включенными в границу безопасности. В большинстве гибридных сценариев проверка подлинности пользователей выполняется через VPN-шлюз или подключение ExpressRoute к локальной среде AD DS.

Для развертывания кластера больших данных в режиме AD решение для интеграции локальной службы Active Directory с Azure должно иметь следующие предварительные требования:

• Учетная запись AD имеет определенное разрешение на создание пользователей, групп и учетных записей компьютеров в предоставленном подразделении в локальном каталоге Active Directory.
• DNS-сервер для разрешения внутренних DNS-запросов. Он должен содержать записи A (пересылка поиска) и PTR (обратный поиск) на DNS-сервере с именами в этом домене. Укажите параметры DNS домена в профиле развертывания кластера больших данных.

Next steps

Руководство по развертыванию кластеров больших данных SQL Server в режиме AD в службах Azure Kubernetes (AKS)