На сколько безопасно хранить креды от БД в config.php (ну или таким же по смыслу файле, но с другим названием), даже если он находится в gitignore?
И каким способом можно себя максимально обезопасить, где хранить креды?
Но тогда нужно быть уверенным, что нигде в отладочных скриптах или панелях администрирования не используется ф-я phpinfo, которая с потрохами переменные окружения сдаст)
Имхо, переменные окружения плохой выбор, т.к. никто не предполагает, что в них может храниться какая-либо секретная информация. Файл не доступный по веб, с правами чтения только для веб-сервера и настройками СУБД ограничивающими подключения, вполне достаточное решение.
Спасибо за ссылки, было интересно почитать. Но отмечу, что претензий к хранению в файлах 2:
1) "случайно можно запушить в реп" - случайно можно и не такое сделать, будьте внимательны, в крайнем случае, настройки dev-окружения в репе никого не могут дискредитировать, а вот засвеченные переменные окружения на проде могут.
2) "легче управлять при разнородных системах, языках программирования и т.д." - здесь абсолютно согласен. Но у нас ведь не та ситуация, не всем нужен docker, а многим и CI/CD не нужен.
Поэтому для конфига БД проекта на PHP такие утверждения не истина в последней инстанции. Решения должны быть соизмеримы задаче. Да и в разработке будет не удобно (развернуть несколько инстансов на одной машине, например).
Vitsliputsli, на счёт п.2 справедливо только если человек совсем не опытный. Как только появляется хоть какой-то правильный опыт все старые подходы неожиданно становятся неудобными и вредными)
Иван Шумов, так чем вреден и неудобен подход хранения в файле? Для 12factor это нужно для централизованного управления и более никаких плюсов, это облегчает жизнь специалистов по деплою при работе с десятками разнородных систем, не более того. Используя файлы я могу, к примеру, развернуть несколько инсталляций на одной машине, для переменных придется придумывать костыли. Имхо, вы слишком полярно смотрите на вещи, не бывает идеального универсального решения на все случаи жизни.
Если я не прав, приведите, пожалуйста, аргументацию, чем такой подход выигрышнее. А то вы твердите про неудобство и вредность, а объяснить выгоду не можете.
Алексей Ситников, переменные окружения хранятся в памяти исполняемого окружения - будь то контейнер, виртуалки или железка) А так же могут быть прописаны в соответствующие места, в зависимости от системы, чтобы даже при перезагрузке все работало. Откуда у тебя такая не верная информация?
Vitsliputsli, чтобы понимать что удобно, безопасно или вредно нужно понимать это неразделимые вещи - одно следует из другого. Давай по порядку:
- Переменные окружения в файл не положишь (dotenv сейчас не считаем, его в прод даже пакетом уходить не должно). Таким образом в репозитории не будет доступов, которые могут утечь куда угодно: начиная от команды и заканчивая угоном репозитория.
- Переменными окружения гораздо проще управлять. Если у тебя приложение на компилируемом ЯП то его не надо пересобирать при изменении конфигурации.
- Если работаешь с контейнерами то можно иметь любое количество запущенных окружений без каких либо проблем на одной и той же машине
- Для сборки не надо знать структуру приложения: я регулярно вижу что команды начинают писать программу на одном ЯП, а со временем он распадается на микросервисы и язык меняется (частые случаи с переходом с PHP на nodejs или python)
это основные и это очень помогает в разработке. Кроме того конфигурация становится куда прозрачнее - не надо знать в каком файле что такого надо законфигурировать чтобы это все завелось. Вот дали тебе код, а потом что? А потом ты будешь часа полтора бегать по сотне файлов конфигурация, если проект не из трех экранов и пробовать узнавать а что там и как надо конфигурировать
Иван Шумов,
1) "Таким образом в репозитории не будет доступов, которые могут утечь куда угодно"
их там не будет в любом случае, хранение в файле не значит хранение в репозитории. Равно как и использование переменных окружения не значит, что где-то они не лежат в файле.
2) "Переменными окружения гораздо проще управлять. Если у тебя приложение на компилируемом ЯП то его не надо пересобирать при изменении конфигурации"
проще для кого? Для специалистов по сборке с учетом большого парка разномастных проектов - да. Для одного-двух проектов на php и небольшой команды - без разницы.
3) "Если работаешь с контейнерами то можно иметь любое количество запущенных окружений без каких либо проблем на одной и той же машине"
а если нет? Внедрять контейнеризацию? Ради чего? Где те неоспоримые преимущества, ради которых стоит это сделать?
4) "Для сборки не надо знать структуру приложения: я регулярно вижу что команды начинают писать программу на одном ЯП, а со временем он распадается на микросервисы и язык меняется"
ее нужно знать один раз во время написания скриптов автоматизации, что лучше разработчика работающего над проектом никто не сделает. Даже по 12factor требуется привлекать разработчиков к таким задачам.
"это основные и это очень помогает в разработке. Кроме того конфигурация становится куда прозрачнее - не надо знать в каком файле что такого надо законфигурировать чтобы это все завелось. Вот дали тебе код, а потом что?"
Все перечисленное помогает только осуществляющим сборку, не разработчикам, а если таких выделенных людей нет вовсе, то никому не помогает, а только мешает.
Когда мне дадут код, то без разницы в конфиг-файлах лежат доступы или в них только ссылки на переменные окружения, без нормального мануала по сборке придется разбираться долго, ну как я угадаю нужные переменные окружения?
Даже при использовании больших конфигурационных файлов хороший разработчик позаботится о быстром старте и подготовленных конфигах для разных сред окружения, а будет это в виде переменных окружения или отдельных конфиг-файлов не имеет значения.
Резюмируя, я вижу что все это нужно только для облегчения жизни специалистам по деплою на разнородных проектах. Всем остальным это не нужно, и может даже мешать. А заявления про безопасность не обоснованы.
Я не говорю что переменные окружения это плохо, я говорю, что нет никаких явных преимуществ, есть свои плюсы и минусы, как в любом инструменте. Кроме того, при желании можно те же переменные окружения передавать сборщику, а он создаст конфиг-файлы. Главное чтобы было понимание, почему лично вам так удобнее. Не все что применяется в крупной компании подойдет средней или маленькой, да скорее всего даже другой крупной компании не подойдет. Это как с микросервисами - отличное решение под определенную задачу и ужасное под другую задачу, но сейчас повсеместная эйфория и желание впихнуть их везде.
Иван Шумов, хранение не в файле а в переменной - это новомодная технология? И что здесь учить? Ну что ж, раз по делу сказать нечего, и пошел уже переход на личности, значит задел за живое. А я вот, не ценю людей, которые способны только болтать о своей продвинутости, но не способны объяснить конкретику. Ты как сертифицированный тренер, который с упоением рассказывает о вещах, которых никогда не применял.
