AWS Elastic Beanstalk VPC - HTTPS от ELB до примера

Question

Я пытаюсь найти лучший способ управлять HTTPS для приложения докеров EB.

В настоящий момент я использую следующий подход.

1. ELB принимает HTTPS-соединения на 443 и отправляет порт HTTP 80 на экземпляр.
2. ELB принимает HTTP-соединения на 80 и пересылает в HTTP-порт 8080 на экземпляр.
3. Экземпляр принимает HTTP-соединения на порту 80 и переходит в приложение докеров.
4. Экземпляр принимает HTTP-соединения на порту 8080 и перенаправляет их на HTTPS.

Все это работает достаточно хорошо. Это означает, что приложение докеры не должно беспокоиться о перенаправлении вообще. Он просто слушает порт 80, и все в порядке. Остальные останутся.

Моя единственная проблема с этой настройкой - приложение докеры не знает, что оно работает безопасно. Если в моем приложении я проверю это, он потерпит неудачу.

Я хочу полностью отделить приложение докеров от доменных имен и SSL-сертификатов, которые могут измениться, поэтому я предпочел бы продолжить завершение первоначального HTTPS-соединения в ELB. Мне интересно, есть ли способ заставить хост-докер (или ELB) пересылать (перешифровывать) запрос в протоколе HTTPS, но использовать самозаверяющий сертификат, поэтому я могу сохранить его полностью универсальным.

Просто, чтобы быть ясным, это будет только между хостом ELB и/или докером, а также моим приложением для докеров, а не браузером.

Если я создаю не истекающий самозаверяющий сертификат и зарегистрирую его с помощью веб-сервера в приложении докеры (в настоящее время использую Apache2, но могу потенциально использовать nginx), а затем просто скажите ELB или докере хост для пересылки запросов как HTTPS, будет ли это работать? Или он упадет в какой-то момент, потому что сертификату не доверяют?

Или существует какой-либо способ, чтобы можно было прекратить соединение HTTPS на веб-сервере приложения docker, не требуя предварительного создания сертификата (я не думаю об этом, поскольку, по-видимому, ему нужно будет генерировать сертификат «на лету» или что-то в этом роде).

Есть ли рекомендуемая практика лучшей практики для такого рода вещей?

Answer 1

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

ELB has a page on this и использует следующие заголовки:

• X-Forwarded-For - Клиент IP
• X-Forwarded-Proto - Схема/протокол
• X-Forwarded-Port - Входящий порт.

Обычно вы не разрешаете эти заголовки непосредственно от клиента, если только они не являются доверенным клиентом. Я полагаю, что ELB заботится об этом для вас.