Re: Mutual authentication средствами nginx

Thu Jan 23 11:53:15 UTC 2014

четверг, 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 at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20140123/b275f503/attachment-0001.html>