Как подружить Ovirt и Let's Encrypt

[Retifff]

К примеру, вместо домена Alex-GLuck-Awesome-Company.local, можно смело использовать домен для сайта компании Alex-GLuck-Awesome-Company.com.

Как этом случае, из внутренней сети, попасть на внешний сайт компании Alex-GLuck-Awesome-Company.com?

[AlexGluck]

Когда вы используете домен внутри организации(freeipa, ldap, ad) машины в этом домены создаются с адресами 3его уровня: host1.Alex-GLuck-Awesome-Company.com, host2.Alex-GLuck-Awesome-Company.com, ovirtengine.Alex-GLuck-Awesome-Company.com. И они не пересекаются с именем сайта, следовательно когда вы пытаетесь открыть ресурс по домену у вас днс резолвит интернет адрес сайта, куда вы преспокойненько попадаете. Понятненько?

[Retifff]

Мне-то это понятно, но у вас в статье написано про один и тот же домен. Что я и процитировал.

И причем тут имена машин в домене, вот это мне непонятно, я вроде про официальное имя внешнего сайта, а никак не машин.

[pylaevpa]

Я возможно что то путаю, но проблемы с внешними и внутренними именами доменов и хостов в разных зонах и в одной вполне можно решить за счет Split DNS, данная технология реализована, например, в BIND. Делается это достаточно легко, достаточно погуглить: «Split DNS: заставим BIND работать на два фронта» и прочитать.

[AlexGluck]

Как правило в организациях используется АД и там split zone(название технологии в BIND) или zone view(название технологии в powerDNS) сделать и поддерживать нецелесообразно. Лучше жёстко разделить ДНС записи на публичные и внутруненние по разным ДНС серверам. ДНС для внутренних записей будут переназначать параметры для внешних. А во внешних будет вполне примитивная логика работы, и ограниченный объём по количеству записей.

[pylaevpa]

Абсолютно солидарен с Вами. Так в «продакшене» обычно и происходит. Однако замечу, что данное положение дел может резко измениться если у вас много раздельных внутренних и внешних доменов, принадлежащих разным организациям, но по тем или иным причинам, внезапно, решившим объединить свою инфраструктуру ИТ. Сценарии могут быть разными и каждый сам выбирает, что и как ему будет удобно в его инфраструктуре.

[Retifff]

Не очень понимаю, чем нам поможет Split-DNS в случае одинаковых имен внешнего сайта и домена AD.
Допустим, есть домен AD company.ru и внешний сайт company.ru. Изнутри company.ru будет резолвиться в имена контроллеров домена. И собственно должен в них резолвиться, иначе AD не будет нормально работать.
Попадать на внешний сайт придется всякими извратными путями, не совсем удобными для конечных пользователей. Если знаете какой-то приличный путь, я был бы не против его узнать тоже.

[AlexGluck]

Создайте домен ad.company.ru или office.company.ru. Ну или купите другой публичный домен, если не знаете как совместить одновременную работу публичной и внутренней части.

[pylaevpa]

Как же я с Вами солидарен. Жаль не имею прав, надеюсь пока, «лайкать» комментарии.

[pylaevpa]

Резонный вопрос. Если внутри организации действительно развернут AD DC и его доменная зона совпадает с публичной, то простой и «бескостыльный» метод всё это подружить, приучить сотрудников писать имя хоста сервера где размещен сайт, обычно это «www», например: «www.company.ru» и вопрос уйдет сам собой. В прочих случаях DNS конечно не поможет никак в такой ситуации, так как корень домена в AD DC предопределен и менять данное положение дел очень чревато последствиями, кроме того корень домена это ещё и корень DFS. А что касается «костылей», то если вопрос ограничивается лишь сайтом компании, то веб-прокси сервер внутри компании может закрыть данную проблему, правда это потребует дистрибуции самого этого прокси сервера, что породит отдельную проблему, но в конечном счете каждый сам решает на что он может пойти ради искусства.

[Retifff]

Ну, метод к чему-то приучать пользователей, мне бескостыльным никак не кажется. Это первый из двух известных мне костылей. Второй, это использовать прокси (уже не очень приятно, в век, когда космические корабли бороздят просторы) и на нем перенаправлять HTTP-запросы куда надо.

А бескостыльные, на мой взгляд, это именно что использование для внутреннего домена домена третьего уровня типа office .company.ru, как выше было сказано, или (сюрприз!) использование домена типа .local.

А вообще, учитывая, что у компаний иногда бывают переименования, объединения, разделения и т.п., использование какого-нибудь безликого corp.local мне видится наиболее оптимальным.
Проблемы с сертификатами для доменов .local, мне кажутся надуманными, так как публиковать сертификаты умеет любой мало-мальски приличный реверс-прокси.

[pylaevpa]

Абсолютно согласен и в своих практиках предпочитаю именно такой способ, разве что мне не очень нравится домен «local», как-то длинно и не благозвучно, я лично использую «lan». Мне кажется, все мы говорим об одном и том же, просто автор не достаточно точно описал данный момент в своей статье. И я вообще не до конца понимаю зачем он это сделал, так как данный вопрос лежит за рамками статьи.

[AlexGluck]

Вашему самоподписанному сертификату на зоны local или lan никто не будет доверять. Никакой реверс-прокси не поможет, вы будете использовать 2 зоны тогда. Статья не об этом. Про домены я так понял тема холиварная, я добавлю в план статью с мыслями на этот счёт.

[Retifff]

Никто и не предлагает использовать самоподписанные сертификаты на зоны local или lan. Обычно на реверс-прокси публикуют нормальные публичные сертификаты на внешние зоны.

[Katzman]

На всех контроллерах домена AD в IIS настроен сайт-заглушка-редирект, перенаправляющий на адрес www.company.ru, естественно, на внешний адрес. Всё работает, как часы.

[m_sinelnikov]

Вы всерьёз предлагаете каждый день в 5 утра таскать по SSH с Foreman (который, судя по архитектуре, находится в одной DMZ с oVirt) на бастионный хост в интернете, таскать оттуда закрытый ключ сертификата (privkey.pem) в открытом виде по сети на oVirt-engine, распаковывать его и перезапускать сервисы?

То есть вы сознательно превращаете автоматическое обновление сертификата в регулярный перенос privkey между хостами, нарушая главный принцип: «Закрытый ключ не покидает тот хост, где он был сгенерирован». А если при этом ещё и scp без защиты от перехвата (например, пароль по ssh или незащищённый ключ), то это не «улучшение инфраструктуры», а систематическая утечка ключей шифрования.

Почему это очень плохо:

1. Ключ жил на бастионе → его скопировали на oVirt → теперь он есть в двух местах, включая внутренний хост, который может быть скомпрометирован через веб-интерфейс.

2. Автоматический scp по расписанию означает, что любой, кто получит доступ к Foreman или oVirt, найдёт свежий приватный ключ в файловой системе.

3. Никакого упоминания шифрования канала при передаче ключа (используется ли scp с ключами без пароля? Это ещё хуже).

4. Бэкап ключа (архивирование папки) тоже остаётся лежать на Foreman — ещё один компромат.

Правильный путь: бастион должен быть reverse proxy (nginx с proxy_pass), который сам терминирует TLS, а oVirt вообще не знать про приватный ключ Let's Encrypt. Или использовать certbot с DNS-челленджем, чтобы не таскать ключи между серверами.

[AlexGluck]

К сожалению это не сработает, потому что внутренние компоненты не запускаются без tls шифрования, перенастройка компонентов на использование реверс прокси невозможна, т.к. узлы бастиона и овирта находятся в разных физических сетях. SCM имеет доступ для настройки серверов, компрометация приведёт к гораздо большим последствиям чем утекший ключ.