Добавление PowerShell хоста к vRealize Orchestrator c Kerberos аутентификацией по HTTPS

vladimir vRealize

В данной статье разберем как подключить Windows Sever в качестве PowerShell хоста к vRealize Orchestrator c использованием аутентификации Kerberos и с шифрованием HTTPS. Kerberos и HTTPS являются де-факто стандартами в современном enterprise и ни одна инфраструктура, где есть хоть малейшее понятие о безопасности не пренебрегает ими, а уж тем более та, где есть потребность в продуктах vRealize.

В принципе на первый взгляд может показаться что задача не является «осадой Трои» и никаких подводных камней не ожидается, да и документация у VMware достаточно полная. Но как раз эта задача отняла у меня много времени и что бы сэкономить чьё-то и родился данный пост.

Что мы имеем:

  • Развернутый vRealize Automation & Orchestrator 8.x.
  • Windows Server 2019 добавленный в домен Active Directory.
  • Домен Active Directory
  • Как написано выше аутентификация Kerberos и обмен пакетами по HTTPS для безопасности.
  • Учетная запись с правами Администратора на Windows Server.

А теперь что нам нужно будет сделать.

Включить PSRemoting на Windows Server

Для того чтобы удаленно управлять хостом Windows с помощью PowerShell, эту функцию нужно на нем для начала включить. Это делается простой командой:

Enable-PSRemoting –Force

Данная команда включает службу WinRM, служба переходит в режим автозапуска, создается сокет HTTP на порту 5985, создается правило Firewall и так далее. В общем включается удаленное управление операционной системой.

На современных Windows Server системах (2016 и 2019) PSRemoting включен по умолчанию, но позволяет подключаться только устройствам из той же подсети.

Если же Windows Server в домене (как в нашем случае), то проблем быть не должно и скорее всего PSRemoting настроен с помощью групповых политик.

По умолчанию на Windows Server включен только HTTP листенер на порту 5985 и подключиться по HTTPS не выйдет. По HTTPS WinRM слушает 5986-й порт. Проверить, доступен ли WinRM по HTTPS можно командой:

winrm identify -r:https://<ps-host.domain.local>:5986 -auth:kerberos -u:<username@domain.local> -p:<password> -encoding:utf-8

Запускаем ее на нашей локальной машине и указываем вместо <ps-host.domain.local> — FQDN нашего Windows server, вместо <username@domain.local> – учетную запись локального администратора и вместо <password> его пароль. Скорее всего нам покажут, что соединение не может быть установлено, так как не запущен листенер на HTTPS. Этой же командой можно проверить доступность WinRM и по HTTP, на предмет того настроен ли PSRemoting вообще.

winrm identify -r:http://<ps-host.domain.local>:5985 -auth:kerberos -u:<username@domain.local> -p:<password> -encoding:utf-8

Что бы настроить WinRM на HTTPS, нужно сначала сгенерировать для этого сертификат. Сделать это можно либо с помощью CA (этот пример тут не рассматривается), либо сгенерировать само-подписной сертификат на нашем PowerShell хосте руками. Открываем PowerShell от имени администратора на нашем будущем PS хосте и вводим команду ниже, естественно подставляя свои значения.

New-SelfSignedCertificate -DnsName <ps-host.domain.local> -CertStoreLocation Cert:\LocalMachine\My

В выводе команды получаем Thumbprint (отпечаток) свеже-сгенерированного сертификата, выделяем его и копируем, он нам сейчас пригодиться. Далее открываем уже командную строку от имени администратора и вбиваем следующую команду.

winrm create winrm/config/Listener?Address=*+Transport=HTTPS @{Hostname=”<ps-hostname>”; CertificateThumbprint=”<xxxxxxxxxxx>”}

Где, <ps-hostname> — FQDN нашего PowerShell хоста, а вместо <xxxxxxxxxxx> вставляем отпечаток сгенерированного в прошлом шаге сертификата. Эта команда запускает сокет для HTTPS службы WinRM на нашем PowerShell хосте и определяет для него сертификат. Можно повторно проверить доступность WinRM через HTTPS командой выше и убедиться, что теперь служба доступна. На этом с PowerShell хостом закончили.

Конфигурируем vRO для Kerberos

Так уж получилось, что просто так взять и добавить PowerShell хост к Оркестратору по Kerberos не получиться. Мы получим кучу всевозможных ошибок. И происходит это из-за неготовности vRealize Orchestrator из коробки работать с Kerberos. Что бы исправить это нужно подключиться к vRO по SSH и произвести пару манипуляций. В типовых инфраструктурах vRO работает на одной VM вместе с VRA, но бывают случаи, когда к vRA подключают standalone vRO, работающий на отдельной виртуальной машине. Нужно понимать на какой машине работает интересующий нас Оркестратор и подключаться к ней.

Подключаемся по SHH к vRO, переходим в директорию /data/vco/usr/lib/vco/app-server/conf/.

cd /data/vco/usr/lib/vco/app-server/conf/

Смотрим. Присутствует ли там файл под названием krb5.conf. Если его нет, то создаем, если есть, то редактируем. Нам нужно привести его к следующему виду.

[libdefaults]
default_realm = LAB.LOCAL
udp_preference_limit = 1
[realms]
LAB.LOCAL = {
kdc = LAB.LOCAL
admin_server = LAB.LOCAL
default_domain = LAB.LOCAL
}
[domain_realm]
.lab.local=LAB.LOCAL
lab.local=LAB.LOCAL

Меняем все LAB.LOCAL на имя вашего домена AD. Осторожнее с предпоследней строчкой, там точку нужно оставить. Далее сохраняем конфиг и назначаем ему разрешения 644.

chmod 644 /data/vco/usr/lib/vco/app-server/conf/krb5.conf

Теперь переходим к следующему шагу. Службы Оркестратора, как и в принципе большинство сервисов продуктов VMware работают в контейнерах Kubernetes внутри VM. Нам нужно перезапустить под Оркестратора, что бы он принял новые настройки. Сначала найдем этот под. В консоли SSH вводим команду ниже.

kubectl -n prelude get pods

Нам будет предоставлен список всех подов, работающих на этой VM. Нам нужен под с названием в виде — vco-app-xxxxxx, где xxxx это рамдомный ID. Копируем его название и вводим следующую команду, где подставляем скопированный текст вместо <vco-app-xxxxx>.

kubectl -n prelude delete pod <vco-app-xxxxx>

Данная команда остановит под vRO и потребуется несколько минут для его перезапуска, в это время служба Оркестратора работать не будет. Ждем некоторое время. Можно с помощью команды kubectl -n prelude get pods мониторить запуск пода vRO. После того как под запуститься и vRO станет функциональным можно покинуть консоль SHH и перейти к следующему шагу.

Добавление PowerShell хоста к vRO

Последний этап. Мы подготовили инфраструктуру и осталось дело за малым, добавить хост к vRO. Заходим в панель нашего vRO и переходим в Workflows/Library/PowerShell/Configuration, выбираем Add a PowerShell host и нажимаем RUN. Нам нужно будет заполнить несколько полей и запустить workflow.

На вкладке PowerShell Host заполняем поля:

Name – просто имя ни на что не влияет, но стоит дать его вменяемо.

Host/IP – заполняем FQDN нашего PS хоста, IP адрес или просто hostname не подойдут для Kerberos.

Port – опционально, стоит заполнить если на PS хосте используется отличный от 5986 порт.

Далее вкладка Host Type.

Думаю, тут объяснения излишни. HTTPS, Kerberos и принятие незнакомого vRO сертификата. Следующая вкладка User Credentials.

Session Mode – тут мы можем определить какие учетные данные использовать при работе с этих хостом в дальнейшем, пользователя запускающего workflow (Per User Session) либо определенную учетку (Shared Session). Наш выбор – Shared Session.

User Name – указываем учетку с правами Администратора на PS хосте. Указать нужно именно в виде user@domain.name.

Во вкладке Advanced Options нужно проследить что бы стояло UTF8, остальные параметры опциональны и их можно не трогать. Жмем RUN и через какое-то время PowerShell хост будет добавлен к vRO. После добавления PS хост можно увидеть в Inventory. Далее его можно использовать для запуска PowerShell скриптов, расположенных как нем, так и отправлять на него команды непосредственно с Оркестратора. Результатом выполнения сценариев PowerShell на PS хосте, отправленных с vRO, будет возвращаемый на vRO PS объект, который мы можем использовать для дальнейших действий.

Как видим добавление PowerShell хоста к vRealize Orchestrator с использованием HTTPS и Kerberos не является совсем уж простой операцией и требует определенной подготовки как vRO так и самого хоста.

P.S:

Если мы используем PowerShell в vRO как средство автоматизации работы с Windows инфраструктурой, то хорошим тоном является добавление хоста непосредственно в определенном Workflow для конкретных операций, а затем, когда операции этого Workflow произведены, хост следует отключить и все это в пределах одного Workflow. Это как рекомендация с целью обезопасить инфраструктуру.