В настоящее время у нас есть собственное решение, которое позволяет нашим клиентам добавлять CNAMES для доступа к своему контенту через свои собственные домены.
Мы перемещаем весь стек в Google Cloud, при этом основной продукт находится в развертывании Firebase Hosting, с бессерверными функциями, хранилищем и базами данных Firestore.
Я знаю, что мы можем вручную и программно добавить CNAMES в нашу учетную запись хостинга Firebase, но для Firebase существует жесткое ограничение в 20.
Мой вопрос: предлагает ли GCP решение, в котором мы можем программно добавлять CNAMES, генерировать самоподписанный сертификат и направлять их через прокси-сервер на наш URL-адрес хостинга Firebase, сохраняя исходный CNAME, но обслуживая наш контент Firebase? Или рекомендуемые подходы для этого стека?
То, что мы не хотим делать:
Мы связались с командой Firebase, но нам порекомендовали пункт 1 выше, разделив их между несколькими развертываниями, поскольку они не имели видимости для других продуктов GCP.
Ответ на ваш вопрос заключается не в том, сколько имен хостов может поддерживать Firebase, а в том, сколько имен хостов может поддерживать SSL.
Рекомендация сертификата SSL заключается в том, что в поле SAN сертификата SSL помещается не более 20 записей. Это называется лимитами на чеканку сертификатов SSL. Некоторые сертификаты SSL поддерживают до 100 *, но Firebase поддерживает 20. Чем больше записей, тем больше накладных расходов на обработку каждого соединения. Каждый раз, когда вы добавляете новый домен к сертификату, все существующие домены должны повторно подтверждаться при выпуске нового сертификата.
Примечание. Я не включаю подстановочные знаки (* .example.com).
*Заметка: RFC 5280 не указывает максимум для SubjectAltNames. Microsoft устанавливает максимальный размер закодированного расширения в 4 КБ (ссылка на сайт).