Size: a a a

DevOps — русскоговорящее сообщество

2021 May 17

j

jenia in DevOps — русскоговорящее сообщество
Согласен на счет слова
источник

AK

Andrey Kartashov in DevOps — русскоговорящее сообщество
в общем случае, если у вас "шина" умеет отсеивать недоверенные сервисы, то авторизация не обязательна. Если же каждый сервис должен проверять "права" в запросе - можно передавать jwt
источник

j

jenia in DevOps — русскоговорящее сообщество
В том и беда что хочу попробовать сделать для себя впервой микросервисную архитектуру. Представляю что это такое достаточно нормально. Думал что если фильтровать на уровне маршрутизатора доступ то к нему и так никто не подключиться. Но тогда в каких случаях могут ключи понадобится ? Пока только мысль о том что одним сервисом будут пользоваться несколько компаний и нужно будет передавать ключ в конечный микоросервис для определения прав и маршрутизации. А так я пока не знаю зачем он нужен
источник

AK

Andrey Kartashov in DevOps — русскоговорящее сообщество
в конечном микросервисе достаточно проверять подпись jwt
источник

j

jenia in DevOps — русскоговорящее сообщество
так я вот и говорю что зачем это если на сервисе до него уже бует проверка например ? запрос может максимум дойти до микросервиса аутентификации
источник

AK

Andrey Kartashov in DevOps — русскоговорящее сообщество
zero trust network
источник

AK

Andrey Kartashov in DevOps — русскоговорящее сообщество
проще изначально проверять всех, чем рассчитывать на то, что кто-то правильно настроит файрвол
источник

j

jenia in DevOps — русскоговорящее сообщество
ну тут то может и правильно ... но затраты на поддержку синхронизации всего наверное будут выше чем настройка  firewall
источник

AK

Andrey Kartashov in DevOps — русскоговорящее сообщество
совсем не обязательно
источник

AK

Andrey Kartashov in DevOps — русскоговорящее сообщество
можно использовать общую библиотеку проверки прав
источник

AK

Andrey Kartashov in DevOps — русскоговорящее сообщество
везде её подключать как middleware
источник

j

jenia in DevOps — русскоговорящее сообщество
как я и сказал что должно проходить через сервис аутентификации все запросы такие
источник

j

jenia in DevOps — русскоговорящее сообщество
+
источник

AK

Andrey Kartashov in DevOps — русскоговорящее сообщество
+ внешний сервис не обязательно знает про права внутреннего, он может просто перенаправлять запросы
источник

AK

Andrey Kartashov in DevOps — русскоговорящее сообщество
то есть вы разделяете уровнеь ответственности. внешний сервис занимается аутентификацией, выдаёт токен, потом этот токен прозрачно транслируется всем внутренним. Внутренние проверяют подпись jwt и в соответствии с содержимым (например в jwt содержится имя пользователя и группы) дают право на выполнение конкретного запроса, например разрешая одному токену чтение, другому чтение и запись, третьему ещё что-то на какой-то скоуп ресурсов - то есть занимаются авторизациейц
источник

AK

Andrey Kartashov in DevOps — русскоговорящее сообщество
когда у вас появляется новый внутренний сервис, он может ввести свои абстракции прав, про которые внешний сервис ничего не знает, и это его не затронет
источник

j

jenia in DevOps — русскоговорящее сообщество
Спасибо. Нужно подумать пока засыпать будут
источник

WE

Win Excelent in DevOps — русскоговорящее сообщество
Всем привет! Пытаюсь разобраться как делать полный бекап VPS сервера Ubuntu 20.04.2 LTS, наткнулся на duplicity и начал тестировать, написал такой простенький скрипт для бекапа, бекап делает замечательно, сначала полный затем инкрементальный если команду повторить.
источник

WE

Win Excelent in DevOps — русскоговорящее сообщество
Далее я написал скрипт для восстановления системы из текущих бекапов, и при его запуске получаю кучу ошибок.
источник

WE

Win Excelent in DevOps — русскоговорящее сообщество
источник