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

[Gena Makhomed]

On 23.01.2014 8:40, Илья Шипицин wrote:

>> Все что связано с сертификатами и TLS/SSL хотелось бы оставить
>> на уровне nginx, чтобы веб-сервисам приходил plain http,
>> и разработчикам этих веб-сервисов не приходилось бы потом
>> заморачиваться с https-запросами и клиентскими сертификатами.
>
> это чревато тем, что для приложения вся ваша магия выльется в "еще
> одну точку отказа", как вы выразились.
> как приложение отреагирует, если магия сломается ? а сломаться она
> может легко, например, нет доступа к CRL-ке и сервер не принял
> сертификат, который ему предъявил nginx

Еще одной точки отказа тут нет, nginx в любом случае используется.
nginx стартует с рутовыми правами и доступ к сертификатам у него есть.
Если сервер не принял сертификат - значит у этого клиента доступа нет.

Если вся логика работы с TLS/SSL будет только на уровне nginx - это
нормально, а если часть там, часть там - то это layering violation.

>> Если веб-приложение работает как сервер - ему запрос приходит
>> на 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
ту функциональность, которой там сейчас нет, в частности, передачу
на удаленный сервер клиентского сертификата и проверку серверного?

>> Скорее всего - такой функциональности сейчас в 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 между сервисами.

В любом случае, наличие такой 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.

==========================================================

Вторая задача - это большой веб-сервис, который построен
с использованием Micro Service Architecture, физически
размещен на нескольких серверах с горизонтальным масштабированием
наиболее высоконагруженных подсистем. Причем все эти микросервисы
могут "на ходу" добавляться/убираться/перестраиваться,
здесь тоже идеально подходит вариант когда Mutual authentication
делает сам nginx, а между nginx и tomcat`ами будет только plain http:

    tomcat1 =(http)=> nginx1 =(HTTPS)=> nginx2 =(http)=> tomcat2

Разве в будущем создание серверных систем пойдет не в этом направлении?
У nginx сейчас вот есть возможность создать и возглавить такой тренд...

-- 
Best regards,
  Gena