AN
ну или другой кейс, я хочу понять по логам, кто сделал запрос в сервис А. Откуда был запрос, из сервиса Б или из сервиса Д?
Size: a a a
2021 June 24
AN
Ну вопрос как раз в том как понять кто ее меняет? Вы же советуете, на сколько я понял, вообще ничего не спрашивать если сервисы в изолированной сети.
SB
в чем проблема нджинкс же знает откуда пришел запрос?
SB
Просто запишите в нее кто ее меняет если вам это важно. Добавьте требование сообзить кто это в контракт.
Не важно где они я да советую ничего не спрашивать советую чтобы по большей части они вообще не знали что они не одни на этом белом свете
Не важно где они я да советую ничего не спрашивать советую чтобы по большей части они вообще не знали что они не одни на этом белом свете
AN
не понял, откуда он это знает? Он же по заголовкам может только это определить? кто мешает мне эти заголовки подделать?
SB
Так сеть закрытая вы все контролируете
зачем вам что то подделывать?
зачем вам что то подделывать?
SB
Вы от самого себя защитится хотите или как?
AN
Да нет, я про то что изолированная сеть, тоже ведь не гарантия безопасности. Всякого рода SSRF к примеру не исключается.
AN
В общем, на сколько я понял, вы советуете просто подпись в заголовке передать для межсервисного общения, и на этом все? остальное это моя параноя?
SB
Ну да
все протоколы на этом основаны обычно
все протоколы на этом основаны обычно
SP
Это opentracing гугли
SP
По сути у каждого сервиса свой идентификатор (идентити) должны быть. Так ты можешь узнать если операцию именно сервис инициировал.
В целом всякие openid эти кейсы покрывают
В целом всякие openid эти кейсы покрывают
AN
он ведь не дает понять от кого запрос, он дает понять типа цепочку запросов
AN
Его нельзя разве подделать? То есть ну вот я указал в заголовке какой то условный client_id. Тогда сервис должен на слово поверить что его не подделали? или тут надо ключами шифровать его?
SP
Важно ещё что обычно сервисы сами токены не выдают. Могут и есть кейсы но "обычно" есть identity server
SP
Подпись тогда надо подделывать, так что не.
AN
так и есть, есть этот identy server. Но получается еще и так что только он и может провалидировать токен. Вот думаем как эту валидацию убрать с него, чтобы не плодить лишние запросы к нему.
SP
Он даёт публичный ключ которым ты можешь валидировать подпись.
Минус только в том что Access token надо выдавать на оч маленькое время (пару минут).
Минус только в том что Access token надо выдавать на оч маленькое время (пару минут).
SP
Но по подписи проверять безопасно.
AN
Ок, спасибо. В целом думаю мы примерно так и поступим. Будем просто проверять что JWT именно от нашего сервиса. А все остальное положим в payload. По времени мы вроде решили что пока что на 15 минут будем его выдавать