Комментарии 36
Как часто Вы передаёте конфиг приложения в виде аргументов командый строки? :) (А он, вероятно не маленький)
Разве что вносить наш файл в .gitignore, но это, конечно, вообще не решение.
Конечно же решение, почему нет?
Это просто не удобно. По крайней мере для меня.
Я не понимаю. Обычные текстовые конфиг-файлы ведь тоже нужно заносить в .gitignore, чтобы случайно не закоммитить. Что я и делаю во всех своих проектах, где есть какие угодно конфиги — хоть текстовые, хоть кодом. И даже если переменные окружения приспичит хранить где-то в env-файле рядышком, то этот файл тоже должен быть в .gitignore
Для файлов конфигурации (чаще всего .env) я просто оставляю .env.example. Конечно, это решает проблему и с config.py. Но это скорее непервостепенная проблема, мы до сих пор храним данные в коде, где им быть не надо.
я просто оставляю .env.exampleЭто никак не отменяет возможности случайно закоммитить .env, прецеденты были (обычно среди неопытных погромистов, пишущих git add . не глядя, но всё же)
мы до сих пор храним данные в коде, где им быть не надо.
Ну это да. Хотя вот у меня насчитывается как минимум четыре проекта, где нужно частично передать контроль над логикой работы программы пользователю, и приходится городить «тьюринг-полный» конфиг тем или иным образом — или в Lua-песочнице пользовательские скрипты гонять, или наплевать на песочницу и Python-функции прямо в конфиг помещать, или шаблонизатор Jinja2 подключаю если его возможностей достаточно, или что-нибудь ещё в таком духе
А почему мы не можем в проекте иметь файл config.py который содержит пустые параметры. Таким образом не нужно настраивать .gitignore и бояться слива данных. А реальный файл конфигурации подавать на вход.
А вообще — спасибо.
В разработке год, делаю первый большой проект, и под финал сборки задумался «ёпрст, все токены же можно будет увидеть, и на**евертить в проекте, при желании». Стал искать пути скрытия токенов и данных. Т.к. проект на Амазоне хостится, там есть KMS (Key Management System), а для других проектов, и вообще более мелких — не знал как быть с конфигами.
Гугл выдавал 100500 статей, которые представляли из себя либо «вот 100500 способов как у вас украдут логин-пассы» либо «вот почему надо защищать логин-пассы». И статьи супер-задротным языком, которые начинающему не понять без пол-литры.
Поэтому — спасибо за статью, теперь хоть знаю, что гуглить, чтоб детальнее вникнуть.
Пользуюсь dynaconf
Умеет в большинство популярных форматов, есть интеграции с Джангой и Флаской, умеет в Vault.
Конечно, есть json ..., но придётся написать кучу… кода
cfg = json.load(open("config.json", "r"))Что не так с кучей?
Не стоит вырывать из контекста. Там ещё yaml упоминался :)
cfg = yaml.full_load(open("config.yaml", "r"))Конечно, есть json в стандартной библиотеке и pyyaml, но придётся написать кучу (ну, или не совсем) кода для этого.
Я тут плавно подводил, что следующий вариант в этом плане будет поприятнее в использовании. Конечно, эта задача ни разу не сложная и решается в две строки, но ведь удобство тоже важно? :)
Согласен, может не совсем точная формулировка (или вообще не точная), но мне кажется работа с конфигами как с сырыми диктами выглядит не очень удобно.
Но… а если нам нужно читать другие конфиги, ну там json или yaml например, или все сразу. Конечно, есть json в стандартной библиотеке и pyyaml, но придётся написать кучу (ну, или не совсем) кода для этого.
По сравнению с тем что вы предложили, гораздо проще отнаследоваться от congigparser'а и перегрузить метод read, а там по расширению брать и подставлять стандартную реализацию или как вам предложили выше.
Я не осуждаю — сам написал собственный парсер, но цель была — б`ольшая производительность. А говорить, что стандартный парсер требует кучи кода (5 строк), а потом рекламировать самописку, которая действительно много требует — это странно.
Итак, берем ту же Django. Вы помните сколько там всего можно переопределить? А еще и из библиотек добавим параметры…
Как просто и быстро решить эту задачу?
OAUTH2_PROVIDER = {
'SCOPES': {'read': 'Read scope', 'write': 'Write scope'},
'ACCESS_TOKEN_EXPIRE_SECONDS': 24 * 3600,
}
REST_FRAMEWORK = {
'PAGE_SIZE': 20,
'MAX_PAGE_SIZE': 1000,
'DEFAULT_PERMISSION_CLASSES': (
'rest_framework.permissions.IsAuthenticated',
),
'EXCEPTION_HANDLER': 'apiv1.handlers.custom_exception_handler',
}
EMAIL_BACKEND = 'django.core.mail.backends.smtp.EmailBackend'
EMAIL_HOST = 'smtp.server.name'
EMAIL_PORT = 25
EMAIL_HOST_USER = 'user'
EMAIL_HOST_PASSWORD = 'password'
EMAIL_USE_TLS = True
EMAIL_USE_SSL = False
DEFAULT_FROM_EMAIL = 'email@email'
SERVER_EMAIL = 'email@email'
Django — отдельный случай. Если вся экосистема юзает это, то использовать что-то другое — плохая идея.
А что вам конкретно не понятно? Если всё из мира джанги завязано на этом — зачем исхитряться?
Затем, уже в следующем разделе, вы развиваете эту мысль. Опять же, читатель заинтригован и не может усидеть, все ждет решения этой проблемы.
Внезапно оказывается что для именно Джанги это ваше решение не очень удобно. И исхитряться не надо?
Как же так, автор?
Комрадам в комментариях пропагандирующих vault. Не путайте secret storage с config storage. Первое для sensitive информации, второе для конфигурации. Если уж на то пошло то статья в целом про микс первого со вторым, соответственно логичней в таком случае говорить и про Consul, в котором как раз можно спокойно хранить конфигурацию.
Но есть же dynaconf, dotenv и dotenv-linter для файлов .env. Зачем ещё один велосипед?
Эта сова натягивается на глобус с очень большими усилиями. Давайте присмотримся по-внимательнее к аргументации в этих статьях.
Первая ссылка
1) The environment is implicitly available to the process. It's hard to track access and how its content gets exposed. It's easy to grab the whole environment and print it out (can be useful for debugging) or send it as part of an error report for instance.
Заменяем слово environment на config file и… ничего не меняется.
2) The whole environment is passed down to child processes (if not explicitly filtered) which violates the principle of least privilege.
Здесь стоит различать ситуации, когда этот child process содержит или не содержит вредоносный код, т.е. пытается ли он атаковать наше приложение. Если не пытается — он просто не полезет в неизвестные ему переменные окружения и не увидит наши секреты. Если пытается — он и к конфиг-файлу доберётся без проблем (т.к. запущен с теми же правами, что и наше приложение).
"Принцип наименьших привилегий" — звучит красиво, но по сути привилегий ровно столько же, вопрос в том, через какой системный вызов их считывать — из окружения или файла.
So your secret keys are implicitly made available to any 3rd-party tools you're using (like ImageMagick to resize an image).
Лежащий на винте и доступный конфиг не менее "неявно доступен", чем переменные окружения.
It's hard to say what those 3rd-party tools will do with the environment, especially in rare occasions like crashes.
И вот капелька здравого смысла: мы не знаем, что может нечаянно сделать сторонняя утилита при креше, но предполагаем, что она с большей вероятностью как-то опубликует наши переменные окружения, нежели наш конфиг-файл.
3) External developers are not necessarily aware that your environment contains secret keys. By doing so your requirements (tightly controlled access) no longer match with most developers implicit expectation (nothing special in the environment, just generic system configuration). This is a dangerous mismatch.
Неизвестно кто делает неизвестно что без понимания как работает наша система, и, сюрприз, он может облажаться. Невероятно, да? Но не будем придираться, просто снова заменим слово environment на config file… и снова смысл не изменился.
Вторая ссылка (за вычетом аргументов повторяющих предыдущие)
It's common to have applications grab the whole environment and print it out for debugging or error reporting.
Да. И не менее общее место когда приложение из тех же соображений выводит свою текущую конфигурацию (иногда это непосредственно конфиг файл целиком, но гораздо чаще это структура в памяти, и в этом случае совершенно без разницы, заполнялась она из переменных окружения или из конфиг файла).
Putting secrets in ENV variables quickly turns into tribal knowledge. New engineers who are not aware of the sensitive nature of specific environment variables will not handle them appropriately/with care (filtering them to sub-processes, etc).
В целом это проблема не столько переменных окружения, сколько общего подхода. С одной стороны, особого смысла фильтровать переменные нет. С другой, если очень хочется их фильтровать, то надо всем переменным нашего приложения дать общий префикс, и код фильтрации написать один раз, универсальный, по этому префиксу — какой смысл удалять из окружения только секреты, если можно удалить все свои настройки разом?
Overall, secrets in ENV variables break the principle of least surprise, are a bad practice, and will lead to the eventual leak of secrets.
Опять же, что есть наименьший сюрприз? 12-factor существует уже очень давно, и очень многими он принят как подход по умолчанию… что подразумевает как раз хранение конфигурации в переменных окружения. Так что лично для меня наименьшим сюрпризом будет ожидать, что секреты передаются либо через переменные окружения, либо через специализированные сервисы вроде vault (впрочем, данные для доступа к vault всё-равно обычно будут в переменных окружения).
Резюмируя
Кто-то в интернете считает, что вероятность случайной утечки секретов из переменных окружения выше, чем из конфиг-файла. Это мнение ничем не подтверждается, никто не приводит реальную статистику утечек. Даже если это так, нет никакой оценки насколько конкретно выше эта вероятность.
При этом надо отметить, что в условиях использования контейнеров передавать конфиги обычно заметно менее удобно, чем переменные окружения. Более того, формирование этих конфигов и доставка их безопасным способом на все узлы системы так же создаёт дополнительные сложности (особенно в системах с динамическим масштабированием серверов). Чтобы понимать, окупятся ли эти сложности нужна как раз вышеупомянутая статистика, конкретные цифры — а их нет.
В качестве вишенки на торте стоит отметить, что никто не мешает при старте контейнера переместить значения из переменных окружения в файл перед запуском нашего приложения. Если прям очень надо. Но смысла в этом особого нет.
В общем, не надо поднимать панику на пустом месте!
Конфигурационные файлы в Python