Недавно обсуждали с коллегами этот вопрос и вот, до чего договорились.
Файл .env для хранения секретов для фронта не подходит, т.к.:
1) файл .env хранится в репозитории с кодом и секреты из него будут доступны всем, кто имеет доступ к репозиторию с кодом,
2) как правило, приложение для запуска собирается в контейнер (например, докер-контейнер). При использовании .env файла, нужно:
- отдельно собирать контейнер для разных окружений (для разработки, для тестов и для продуктива),
- продумывать механизм подстановки разных .env файлов для сборки контейнеров для разных сред.
Файл .env для хранения секретов для бэкенда (jvm-стек) не подходит, т.к.:
1) те же причины, что и для фронта,
2) в jvm-стеке есть механизмы для передачи приложению параметров для запуска и переменных окружения (application.properties, gradle.properties, System.getenv("name"), Vault, Zookeeper, Etcd и т.д.),
3) можно случайно через актуатор раскрыть в проде переменные из .env файла.
Выводы:
При использовании .env файла для хранения секретов:
- теряется универсальность (собрали контейнер 1 раз, используем его во всех окружениях),
- добавляется ручная работа (часто разные .env файлы для разных окружений хранятся в разных ветках репозитория и всё это управляется разработчикм руками),
- добавляются риски безопасности.