Необходимо использовать LockBox как secrets provider в нашем бекенде.
Текущий подход:
Все секреты лежат в файле appSettings.json (-Prod.json, -Dev.json), приложение при старте читает файл в память и использует секреты.
Перед билдом docker image файл appSettings.json заполняется и кладется внутрь image.
Данный подход имеет ряд недостатков:
1) Мы вынуждены собирать docker image для конкретного окружения (потому что для разных окружений разные секреты)
2) Мы не можем публиковать наши docker images в публичном репозитории (потому что любой может скачать себе image и посмотреть что лежит внутри)
3) Существуют класс уязвимостей, которые позволяют читать файлы на файловой системе - это потенциальная утчека секретов (аналогично и для переменных окружения)
4) Секреты меняются в нескольких местах: в LockBox, в GitHub Secrets. (В GitHub они лежат для заполнения файла appsettings.json)
Новый подход:
Используем LockBox как источник секретов. Приложению при старте в виде переменной окружения выдается JWT токен ограниченной длительностью (10 мин), который можно обменять на IAM токен . При помощи IAM токена приложение может получить доступ к LockBox и взять нужные секреты благодаря открытому REST API .
Новый подход решает ранее описанные минусы:
1) Мы можем собирать один контейнер под разные окружения: приложение само будет определять какие секреты ему брать из хранилища благодаря переменной окружения DOTNET_ENVIRONMENT
2) Мы не храним никакие секреты внутри docker image, а храним лишь информацию о том, как получить секреты
3) У нас ничего не лежит в файловой системе; В переменных окружения лежит JWT токен с ограниченным сроком жизни (10 мин), а также он становится невалидным после первого обмена (который совершается нашим приложением при старте): похищение JWT токена не дает возможности украсть секреты
4) Все секреты меняются в одном месте - LockBox
Минусы нового подхода:
1) После перезапуска контейнера (если это было позже 10 минут после старта), то контейнер не сможет прочитать секреты
putilove
commented
9 months ago
Необходимо использовать LockBox как secrets provider в нашем бекенде.
Текущий подход: Все секреты лежат в файле appSettings.json (-Prod.json, -Dev.json), приложение при старте читает файл в память и использует секреты. Перед билдом docker image файл appSettings.json заполняется и кладется внутрь image.
Данный подход имеет ряд недостатков: 1) Мы вынуждены собирать docker image для конкретного окружения (потому что для разных окружений разные секреты) 2) Мы не можем публиковать наши docker images в публичном репозитории (потому что любой может скачать себе image и посмотреть что лежит внутри) 3) Существуют класс уязвимостей, которые позволяют читать файлы на файловой системе - это потенциальная утчека секретов (аналогично и для переменных окружения) 4) Секреты меняются в нескольких местах: в LockBox, в GitHub Secrets. (В GitHub они лежат для заполнения файла appsettings.json)
Новый подход: Используем LockBox как источник секретов. Приложению при старте в виде переменной окружения выдается JWT токен ограниченной длительностью (10 мин), который можно обменять на IAM токен . При помощи IAM токена приложение может получить доступ к LockBox и взять нужные секреты благодаря открытому REST API .
Новый подход решает ранее описанные минусы: 1) Мы можем собирать один контейнер под разные окружения: приложение само будет определять какие секреты ему брать из хранилища благодаря переменной окружения
DOTNET_ENVIRONMENT2) Мы не храним никакие секреты внутри docker image, а храним лишь информацию о том, как получить секреты 3) У нас ничего не лежит в файловой системе; В переменных окружения лежит JWT токен с ограниченным сроком жизни (10 мин), а также он становится невалидным после первого обмена (который совершается нашим приложением при старте): похищение JWT токена не дает возможности украсть секреты 4) Все секреты меняются в одном месте - LockBoxМинусы нового подхода: 1) После перезапуска контейнера (если это было позже 10 минут после старта), то контейнер не сможет прочитать секреты
Задачи: