В этом ответе предполагается, что вы уже включили https в группе безопасности балансировщика нагрузки, добавили сертификат SSL в балансировщик нагрузки, перенаправили оба порта 80 и 443 балансировщиком нагрузки и указали свое доменное имя в среде Elastic Beanstalk с помощью Route 53. (или аналогичная служба DNS).
ПРИМЕЧАНИЕ. Этот ответ предназначен для сред Elastic Beanstalk, в которых используется Apache. Это может не работать для развертывания на основе докеров.
Все, что вам нужно сделать, это добавить следующее в один из ваших .configфайлов в .ebextensionsкаталоге вашего проекта :
files:
"/etc/httpd/conf.d/ssl_rewrite.conf":
mode: "000644"
owner: root
group: root
content: |
RewriteEngine On
<If "-n '%{HTTP:X-Forwarded-Proto}' && %{HTTP:X-Forwarded-Proto} != 'https'">
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R,L]
</If>
Объяснение
Это умеренно прямолинейно за пределами Elastic Beanstalk. Обычно добавляют правило перезаписи Apache, подобное следующему:
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
Или, если за балансировщиком нагрузки, как мы в этом случае:
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R,L]
Однако эти конфигурации работают только внутри <VirtualHost>блока. Изменение RewriteCondк <If>блоку позволяет ему работать должным образом за пределами <VirtualHost>блока, что позволяет нам поставить в в автономном Apache конфигурационный файл. Обратите внимание, что стандартная установка Apache на CentOS (включая установку на ElasticBeanstalk) включает соответствие всех файлов /etc/httpd/conf.d/*.conf, что соответствует пути к файлу, в котором мы храним этот файл.
-n '%{HTTP:X-Forwarded-Proto}'Часть состояния предотвращает его переадресации , если вы не за балансировки нагрузки, что позволяет иметь общую конфигурацию между производственной Evironment с балансировки нагрузки и HTTPS, а также промежуточную среду , которая является один экземпляр и не имеет HTTPS. В этом нет необходимости, если вы используете балансировщики нагрузки и https во всех своих средах, но это не повредит.
Плохие решения, которые я видел
Я видел много плохих решений этой проблемы, и стоит просмотреть их, чтобы понять, почему это решение необходимо.
Используйте Cloudfront: некоторые люди предлагают использовать некэшированную настройку Cloudfront перед Elastic Beanstalk для перенаправления HTTP на HTTPS. Это добавляет совершенно новую услугу (тем самым усложняя), что не совсем подходит (Cloudfront - это CDN; это не подходящий инструмент для принудительного использования HTTPS для изначально динамического контента). Конфигурация Apache - нормальное решение этой проблемы, а Elastic Beanstalk использует Apache, так что мы должны идти именно так.
SSH на сервер и ...: Это полностью противоположно Elastic Beanstalk и имеет так много проблем. Любые новые экземпляры, созданные с помощью автомасштабирования, не будут иметь измененной конфигурации. Любые клонированные среды не будут иметь конфигурации. Любое количество разумных изменений среды уничтожит конфигурацию. Это просто плохая идея.
Перезаписать конфигурацию Apache новым файлом: это попадает в правильную область решения, но оставляет вас с кошмаром обслуживания, если Elastic Beanstalk изменяет аспекты настройки сервера (что они вполне могут сделать). Также смотрите проблемы в следующем пункте.
Динамически отредактируйте файл конфигурации Apache, чтобы добавить несколько строк: это хорошая идея. Проблема заключается в том, что он не будет работать, если Elastic Beanstalk когда-либо изменит имя своего конфигурационного файла Apache по умолчанию, и что этот файл может быть перезаписан, когда вы меньше всего этого ожидаете: https://forums.aws.amazon.com/thread .jspa? threadID = 163369.