У меня есть облачное (Amazon AWS, Rackspace и т. Д.) Мультитенантное приложение SaaS, и мне нужно поддерживать связь по протоколу HTTPS для нескольких несвязанных доменов клиентов.
В качестве наглядного примера предположим, что наш SaaS доступен по адресу:
https://foo.com
Арендаторы могут получить доступ к своему пользовательскому интерфейсу и конечным точкам службы для конкретного клиента через
https://tenantA.foo.com
https://tenantB.foo.com
...
Сегодня это легко поддерживать с помощью одного подстановочного SSL-сертификата.
Тем не менее, с нашим SaaS наши клиенты могут захотеть предоставить наш пользовательский интерфейс (но фирменный для них) напрямую для их собственный пользователей.
Это вызывает проблему: допустим, Джон Смит является существующим клиентом tenantA (и не знает foo.com). Если Джон Смит направлен к https://tenantA.foo.com, они могут легко запутаться (например, «кто, черт возьми, такой foo.com? Почему я здесь? Меня взламывают? Аааа!»).
Чтобы избежать этой проблемы, наши клиенты должны создать субдомен, например:
https://foo.tenantA.com
Это позволяет избежать путаницы у конечного пользователя: tenantAпользователи могут видеть URL-адрес, который, по их мнению, принадлежит tenantA и будет охотнее пользоваться приложением. Но tenantA хочет, чтобы мы разместили все, что связано с приложением, а это значит foo.comинфраструктура должна обслуживать SSL-соединение.
С этой целью мы хотим поддержать следующее:
foo.tenantA.com.foo.tenantA.com быть перенаправлением CNAME на tenantA.foo.com.Таким образом, наш пул балансировщика нагрузки будет обслуживать / прекращать все соединения HTTPS с foo.tenantA.com и все запросы балансируются по нагрузке на наш кластер веб-серверов SaaS.
Это означает, что сертификаты SSL можно добавлять и удалять из пула LB. во время выполнения. Изменения не могут прервать возможность обслуживания существующих или новых запросов HTTPS.
Кроме того, поскольку мы будем развертывать виртуализированное оборудование (например, EC2) с Linux, у нас нет доступа к оборудованию / центру обработки данных. Это должно быть программное решение, которое может работать в Linux. Он также должен быть высокодоступным (2 или более «узлов» LB).
Кто-нибудь знает о конкретном решении? Например, можно ли настроить Nginx, HAProxy или Squid (или что-нибудь еще) для поддержки этого? Есть ли задокументированный и подходящий «рецепт» или существующее решение?
P.S. Amazon Elastic Load Balancer (на момент написания) не может прагматично удовлетворить эту потребность - для этого потребуется Amazon ELB для каждый арендатор домена. Поскольку каждый ELB должен «пинговать» веб-серверы, если бы у вас было 500 клиентов, у вас было бы 500 ELB, проверяющих конечные точки веб-службы SaaS, - немаловажное снижение производительности.
Обновление 2017-09-13: В настоящее время SNI получил достаточно широкое распространение в основных браузерах, поэтому его, вероятно, можно использовать для обработки запроса, и этот ответ следует считать устаревшим.
Единственный способ поддержать это - иметь IP для каждого из ваших клиентов. При подключении по https соединение зашифровано немедленно, браузер не может сказать: «Я здесь по адресу foo.tenantA.com». Таким образом, единственный способ для сервера узнать, какой сертификат SSL следует использовать для шифрования соединения, основан на IP-адресе, с которого произошло соединение.
Теперь это все еще возможно, но это означает, что вам понадобится много IP-адресов. На самом деле мы делаем именно такую настройку на моей работе. У нас есть 2 активных / активных балансировщика нагрузки, половина IP-адресов на одном балансировщике, другая половина - на другом балансировщике (всего около 500 IP-адресов). Затем у нас есть несколько веб-серверов на внутренней стороне, которые принимают все соединения. Любой веб-сервер может выйти из строя, и балансировщик нагрузки перестанет отправлять ему соединения. Или сам балансировщик нагрузки может выйти из строя, и другой заберет все свои IP-адреса.
Программное обеспечение для балансировки нагрузки, которое делает это, Кардиостимулятор и ldirectord (оба являются основными проектами, и любой дистрибутив, который вы запускаете, должен иметь их в своем репозитории). Само ядро Linux фактически выполняет балансировку нагрузки, а программное обеспечение отвечает только за обработку отказов.
Примечание. Для балансировки нагрузки существует множество альтернатив ldirectord, например оставайся живым и верный. Хотя для программного обеспечения восстановления после сбоя фактического балансировщика нагрузки вам следует использовать кардиостимулятор.
Основные руководства:
это предоставит основные инструкции по настройке кардиостимулятора. Вы можете пропустить все предыдущее, поскольку CMAN является его заменой. Единственное, что вам нужно сделать, чтобы дойти до этого пункта в руководстве, - это установить кардиостимулятор и его зависимости. Остановитесь на разделе 8.2.4. Вам не нужно переходить к разделу 8.3, поскольку он не имеет отношения к тому, что вы делаете.
Когда у вас работает кардиостимулятор, этот предоставит очень простую конфигурацию для балансировки нагрузки http-сервера.
Вы также можете посмотреть этот и этот. Это более подробный обзор кардиостимулятора, его функций и способов их использования.
А как насчет того, чтобы просто порекомендовать клиенту самому накинуть на него тонкую обертку? Что-то вроде этого:
https://api.tenantA.comapi.tenantA.com просто пересылает запрос на https://tenanta.foo.comЯ предполагаю, что пока это скорее крайний случай, он должен работать нормально.