Comments 42
Захватывающая история.
Ну, допустим, надо, прямо очень надо как-то подтолкнуть свой тг канал, заодно немножко рекламки в публичное пространство вбросить, ок. Бывает. Почему бы тогда не написать статью-паровоз, но написать её самому и на интересную тему, достойную здешнего сообщества? Жвачка, многажды пережёванная, всё равно не вызовет у людей желания познакомиться поближе с тем, чего там автор ещё нажевал.
А почему тут считается, что всегда должно быть что-то абсолютно новое? Почему тут нельзя писать про то, что я сделал, что я изучаю сейчас и так далее? Это ведь вроде мой профиль.
Я это написал с нуля сам, не своровал нигде, показал просто то, что я реально сделал. Разве это плохо и никому не нужно?
Вы абсолютно правы, что статья должна быть качественной, и я согласен, что пережеванная жвачка никому не интересна. Именно поэтому я не копировал чужие мысли, а написал эту статью полностью с нуля, основываясь на своем личном, реальном опыте.
Изначально я хотел в раздел постов её отправить, так как понимал, что на статью не особо тянет. Но там ограничение 4000 символов всего
А зачем в X-Forwarded-Proto что-то кроме https? Логично на кадди делать 301 на https и "header_up X-Forwarded-Proto https", разве нет? Или вы http тоже пересылаете?
Ну и наверно стоит еще X-Forwarded-Port слать хотя бы.
В локальной разработке я просто поднимаю два контейнера без обратного прокси, там уже нет https
И этот заголовок не мешает мне работать
так у вас и заголовка нет. если нет реверс-прокси
Извините, не так вас понял, я подумал вы про Питоновскую часть.
В Caddyfile в моем случае и правда можно поставить просто https, но обычно ставят сразу ставят сразу готовый заголовок из входящего запроса через плейсхолдер: {http.request.scheme} или {scheme}
Это, например, если бы я не перенаправлял автоматически на 443 с 80, а поддерживал сразу оба
"Обычно" все таки перенаправляют :)
А вы еще и именно переменную воткнули вместо стокового https, о чем сами же и пишете:
Можно его явно не прописывать, так как Caddy сам ставит его по умолчанию, но он ставит без динамической переменной.
Т.е. на выходе получается лишний код в конфиге чтобы можно было делать неправильно (=пересылать там и http)
Ну и сколько токенов вы зря сожгли на эту "инструкцию"?
expose 9000 не открывает порт наружу
Открывает.
ports: - "127.0.0.1:5432:5432"
Есть ли хоть одна важная причина такое делать? Учитывая, что пароль к базе прямо в compose-файле и лежит..
Однако, FastAPI общается с Caddy по HTTP и не знает, что клиент теперь использует HTTPS, из-за этого он будет генерировать ссылки со схемой http://
.. и поэтому мы с вами сейчас напишем неправильный велосипед.
Казалось бы, в официальной инструкции написано про флаги `--proxy-headers --forwarded-allow-ips='*'` ,но у нас свой путь?
Зачем-то скомканный абзац про VPN, совершенно не в тему.
То есть вы хотите сказать, что если я напишу expose 9000, то смогу обратиться к контейнеру из интернета по публичному айпи?
Учитывая, что пароль к базе прямо в compose-файле и лежит, только я ниже написал, что не забудьте использовать .env, но хорошо я сам должен был это прописать, тут с вами согласен
То есть вы хотите сказать, что если я напишу expose 9000, то смогу обратиться к контейнеру из интернета по публичному айпи?
Да, именно так. Сможете. "expose 9000" означает - слушать порт 9000 по всем интерфейсам (0.0.0.0). Про файрволлы вы ничего не написали, а многие хостинги такими сложностями не заморачиваются. Для базы вы биндите порт на 127.0.0.1, что имеет хоть какой-то смысл (для локального дебага), но тоже совсем небезопасно и, вообще говоря, не нужно.
Контейнеры внутри одного compose-энваромента видят друг друга по именам и порт базы вообще не нужно выставлять. Про .env вы написали для приложения, а пароль для базы у вас в compose файле.
Учитывая, что compose-файл обычно хранится в репозитории - у вас пароль будет приходить дефолтный.
У меня две статьи тут написаны по поводу конфигурации энваромента и более безопасной инициализации секретов.
бля бд вообще можно network_mode: none и цепляться к ней через unix socket :)
Ну тут спорный вопрос что лучше - шарить файл сокета в volume между несколькими контейнерами (явно ставить права и вспоминать что будет как себя вести, если каждый из контейнеров рестартует) или просто довериться файрволлу докера, который он автоматически настроит.
бд вроде бы свои сокеты умеет перезатирать (в отличие от того же нгинкса).
у меня tmpfs volume сделаны для этого и вроде бы норм, правда контейнеры я по отдельности не часто перезапускаю.
бонус в том что сеть не докерная = быстрее работает. хотя для не супернагруженной бд наверное не критично. ну и сети нет у бд, что радует моего внутреннего безопасника.
Разработчики Докера с вами не согласны
expose позволяет объявлять порты только между контейнерами во внутренних сетях
Чаще всего expose-порты используются для автодискавери в traefik
https://docs.docker.com/reference/compose-file/services/#expose
У автора этой статьи в профиле ссылка на свой сайт: http://x.x.x.x (да, IP-адрес).
facepalm.jpg.png
PS. я не придираюсь из-за того что хочу выглядеть умным. Моя главная претензия - человек пишет мануал по безопасности, сам не до конца разобравшись в теме.
Даже если бы там был домен, это не мешало бы узнать айпи
Если бы там был домен - вы бы могли выпустить сертификат и использовать TLS. Именно это я имею в виду, особенно в контексте вашей статьи.
Может быть он джва года ждал возможности выпустить сертификат TLS для IP адреса :-)
И что вы хотите этим сказать? Я сознательно не покупаю домен, так как под мои нужды он мне сейчас не нужен. Зачем тратить деньги на то, что не нужно?
Да пожалуйста, конечно, ваша воля. Вот только писать про "информационную безопасность" в XXI веке на сайте с http без tls - немного непоследовательно.
Ну а уж "разрабатывать мессенджер" и предлагать к нему подключиться (создать пользователя и ввести пароль?) на таком сайте - вообще смахивает на фишинг.
Во-первых, мой сайт хаб, не имеет никаких аккаунтов или данных, которые я боюсь что могут перехватить, там просто одна html страничка.
Во-вторых, про мессенджер, вам любой браузер пишет про небезопасное соединение при вводе данных, а также в самом мессенджере снизу постоянно написано: отсутствует шифрование, отправка сообщений на ваш страх и риск
Ну и самое главное, человек не должен строить себе во дворе небоскреб, чтобы он мог рассказать как его построить и построить его, как я настроил HTTPS другому человеку, при этом не настроил себе
человек не должен строить себе во дворе небоскреб, чтобы он мог рассказать как его построить
Любопытная точка зрения. Вот я не построил ни одного небоскрёба - я уже могу начинать всех учить? Ну типа кирпич и цемент - чё там сложного, правда?
В общем-то снимается большинство вопросов к вам, если вы действительно так думаете - всё понятно. Только не обижайтесь на минусы к статье.
Вы даже не увидели суть моего ответа, я не писал, что человек ни разу не строил. Я написал, что он не должен был его строить для себя именно во дворе, ему может быть достаточно и простенького домика для себя, как и для меня в данный момент достаточно что они на http
Вы привели аналогию - я на неё ответил. Нет, я не считаю что опыта строительства маленького домика достаточно, чтобы учить строить небоскрёбы.
Не надо у себя во дворе, ок. Но вот вам другая аналогия - когда неопрятно одетый человек приходит и начинает учить людей модно одеваться - не стоит думать что ему будут верить.
Минусов, конечно, понаставили, но вспомнилась история с приложением на nodejs, в которое автор вкрячил https, сертификаты и их обновление (прямо в код), вместо того чтобы просто отдать возню с ними nginxу или вот caddy
А это как раз то, о чем в статье. Подозреваю, что разработчик просто не знал что так можно.
Caddy потребляет меньше ресурсов, чем Nginx? А можно пруфы?
ACME завезли и в Nginx.
Как я сделал яишенку на завтрак и посолил её
Это 100% нейрослоп, автор даже отвечает через нейронку на комментарии.
актуальная тема, свежие идеи, качественная реализация, без рекламы!
лови минус в карму
Как я настроил безопасное шифрование данных для сайта с помощью протокола HTTPS и SSL/TLS сертификата