Ця відповідь передбачає, що ви вже ввімкнули https у групі безпеки балансування навантаження, додали сертифікат SSL до балансира навантаження, перенаправляєте балансиром навантаження обидва порти 80 і 443, і вказали своє доменне ім'я на середовище Elastic Beanstalk із маршрутом 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>
Пояснення
Це помірно прямо вперед за межами Еластичного бобового стебла. Зазвичай додається правило перезапису 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