Сквозное шифрование Python Flonk за AWS ALB - PullRequest
0 голосов
/ 24 февраля 2019

У меня есть приложение Python 3 Flask, работающее в кластере ECS.Приложение Flask настроено для работы в режиме SSL.К приложению нельзя получить доступ через ALB Cname, поскольку оно генерирует отказ в соединении, как показано здесь -

curl -Il https://tek-app.example.com/health
curl: (7) Failed to connect to tek-app.example.com port 443: Connection refused

Когда ALB попадает напрямую и игнорирует исключение сертификата SSL, оно работает, как показано здесь -

curl -Il -k https://tek-w-appli-1234.eu-west-1.elb.amazonaws.com/health
HTTP/2 200 
date: Sun, 24 Feb 2019 14:49:27 GMT
content-type: text/html; charset=utf-8
content-length: 9
server: Werkzeug/0.14.1 Python/3.7.2

Я понимаю, что основная рекомендация - запускать его за прокси-сервером Nginx или Apache и устанавливать заголовки X-Forward через их конфиги, но я чувствую, что это больше, чем разработка решения.

Я также попытался включить в приложении следующее -

from werkzeug.contrib.fixers import ProxyFix
...
app = Flask(__name__)
app.wsgi_app = ProxyFix(app.wsgi_app)
...

И теперь это исправление выдает правильные IP-адреса источника в журналах Cloudwatch, но не разрешает соединения через ALB Cname.

Есть ли что-то простое, что я здесь упускаю?

Ответ на первый ответ

Спасибо - Cname указывает на правильный ALB.Я столкнулся с подобной проблемой две недели назад с сервером Apache, и исправление было в том, чтобы убедиться, что X-Forward-Proto использовался в файле Apache vhosts.conf.Поэтому я думаю, что это может быть что-то похожее.

1 Ответ

0 голосов
/ 24 февраля 2019

Я сделал это снова - при разработке локально я отредактировал свой файл / etc / hosts, чтобы иметь локальную запись для воспроизведения.Затем, когда приложение Flask было отправлено в облако и протестировано с того же рабочего стола, оно ссылалось на локальную запись DNS, а не на общедоступный эквивалент, поэтому соединение было отклонено.С удаленной локальной записью все теперь работает.

...