Nginx-ru mailing list archive (nginx-ru@sysoev.ru)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Mutual authentication средствами nginx
четверг, 23 января 2014 г. пользователь Gena Makhomed написал:
On 23.01.2014 8:40, Илья Шипицин wrote:
Все что связано с сертификатами и TLS/SSL хотелось бы оставить
на уровне nginx, чтобы веб-сервисам приходил plain http,
и разработчикам этих веб-сервисов не приходилось бы потом
заморачиваться с https-запросами и клиентскими сертификатами.
это чревато тем, что для приложения вся ваша магия выльется в "еще
одну точку отказа", как вы выразились.
как приложение отреагирует, если магия сломается ? а сломаться она
может легко, например, нет доступа к CRL-ке и сервер не принял
сертификат, который ему предъявил nginx
Еще одной точки отказа тут нет, nginx в любом случае используется.
nginx стартует с рутовыми правами и доступ к сертификатам у него есть.
Если сервер не принял сертификат - значит у этого клиента доступа нет.
еще одна точка отказа тут есть. nginx предъявляет свой сертификат серверу, сервер может отказать либо потому что у пользователя нет доступа, либо в силу того, что сервер не смог скачать CRL
надо либо в одном случае возвращать "temp fail", в другом "perm fail", либо что-то еще, но логику отработки ошибок надо как-то реализовывать на стороне приложения
Если вся логика работы с TLS/SSL будет только на уровне nginx - это
нормально, а если часть там, часть там - то это layering violation.
если вся логика с ssl на стороне nginx, это точка отказа
Если веб-приложение работает как сервер - ему запрос приходит
на http://127.0.0.1:80/ а если веб-приложение работает как клиент
и хочет связаться с другим веб-сервисом - то оно просто отправляет
plain http запрос на http://127.0.0.1:8080/ - здесь слушает nginx
и проксирует этот запрос через https с mutual auth на удаленный сервер.
необязательно на C/C++, можно на nginx-lua за полдня набросать то, что
вы хотите.
Каким образом, разве nginx-lua сможет добавить к proxy_pass
ту функциональность, которой там сейчас нет, в частности, передачу
на удаленный сервер клиентского сертификата и проверку серверного?
content_by_lua и любой креатив в ваших силах ценой, возможно, большого оверхеда
Скорее всего - такой функциональности сейчас в nginx таки нет.
Только не понятно - ее "еще нет" или же "вообще нет и не будет".
Подозреваю, что такая функциональность в nginx будет полезной
не только мне, но и большому количеству других пользователей.
очень легко уйти в холивар насчет "полезно ли большому количеству пользователей"
Можно и не уходить в холивар. Micro Service Architecture сейчас набирает
популярность для создания приложений, вот например, про это написали
даже в анонсе про выход Spring Framework 4.0 GA Release:
http://spring.io/blog/2013/12/12/announcing-spring-framework-4-0-ga-release
Логично же делать максимальный уровень защиты
через Mutual authentication между сервисами.
у нас одна из любимых ошибок - "неидемпотентность сервиса", то есть, к примеру есть несколько экземпляров одного сервиса. мы обращаемся к сервису, делаем запрос "поменяй то-то и то-то", запрос уходит в таймаут, что делать ?
идеальной была бы ситуация, когда многократно выполенный запрос не приводил бы к многократному изменению данных (это ведь, по сути, один и тот же запрос). такие типы сервисов называются "идемпотентными".
если сервис таким свойством не обладает, в каких-то случаях лучше зафейлиться, чем уходить на следующую реплику
а теперь представьте, что вы "прячете" топологию сервисов за nginx, все становится еще сложнее, у nginx в коде события "tcp connect timeout" (когда запрос не ушел и безопасно его еще раз повторить) и "http response timeout" (когда надо быть максимально аккуратным) выглядят одинаково
кстати, надо будет патч на эту тему сделать ))
В любом случае, наличие такой feature никому не помешало бы.
Кому не надо - просто не включают и не пользуются.
Вот, как например, мне совершенно не мешает наличие
модуля image_filter или empty_gif или geoip и т.п.
И возможно это даже будет killer feature, которая позволит
еще больше увеличить % использование nginx в современном
web 2.0 и будущем web 3.0. Если это кому-то интересно.
сейчас немного другой тренд.
скажем так, OAuth
но там вся логика строится на приложении, не на транспорте.
Майкрософт эту тему двигает, у него она называется "Claim based access
control" (раньше любимая тема была RBAC = role based access control)
Это если разные сервисы разных производителей взаимодействуют
между собой, то там да, OAuth. А если - это один сервис, который
решает одну задачу, просто он сам построен не в виде одного большого
монолитного приложения. Этот тренд - Micro Service Architecture
набирает популярность. По крайней мере, раньше такого не было.
тренд бесспорно интересный
Но прежде чем куда-то идти и о чем-то просить - вот сначала
попытался узнать в списке рассылки - может быть я какой-то
неправильный вариант решения для этой задачи придумал
и ее все обычно решают другим, более простым способом?
вариант как вариант.
сейчас модно креативить :-)
А как иначе это можно сделать?
Вот например, реальная задача. Есть небольшой хостинг -
несколько десятков сайтов, которые созданы под заказ.
Вместо того, чтобы для каждого сайта создавать свою админку,
цеплять к ней SSL-сертификат, - проще и удобнее сделать всего
одну админку, куда будут заходить пользователи по https,
и там они смогут управлять своими сайтами. А сами сайты:
www.example.com - сюда ходят пользователи сайта
api.example.com - сюда ходит админка с Mutual authentication
Сейчас - сайтов десятки, потом может быть сотни и тысячи.
И что делать, настраивать и поддерживать в живом состоянии
сотни и тысячи stunnel`ей? Каждому выделяя свой отдельный
порт на стороне контейнера с админкой? Это будет nightmare.
Практически это нереальный вариант. Наверное придется таки
идти на layering violation и обучать админку делать https-
запросы с предъявлением клиентского сертификата через curl.
реальна задача- это замечательно, но я не понял, в каком месте возникает профит от mutual authentication, вероятно, надо больше деталей
если вы хотите проверять серты на nginx и сообщать приложению, это делается через переменные nginx, у нас такой сценарий используется, могу конфиги помочь составить
==========================================================
Вторая задача - это большой веб-сервис, который построен
с использованием Micro Service Architecture, физически
размещен на нескольких серверах с горизонтальным масштабированием
nginx ломает идею горизонтального масштабирования, или вы планируете горизонтально плодить много экземпляров nginx?
наиболее высоконагруженных подсистем. Причем все эти микросервисы
могут "на ходу" добавляться/убираться/перестраиваться,
здесь тоже идеально подходит вариант когда Mutual authentication
делает сам nginx, а между nginx и tomcat`ами будет только plain http:
tomcat1 =(http)=> nginx1 =(HTTPS)=> nginx2 =(http)=> tomcat2
Разве в будущем создание серверных систем пойдет не в этом направлении?
У nginx сейчас вот есть возможность создать и возглавить такой тренд...
тренд прикольный
--
Best regards,
Gena
_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru
_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru
|
