Рекомендации devops по адресу https://12factor.net/config предлагают помещать секреты сайта (пароли базы данных, ключи API и т. Д.) В переменные среды. Какие преимущества это имеет вместо использования текстовых файлов (JSON, XML, YAML, INI или аналогичных), игнорируемых в управлении версиями?
Я считаю, что гораздо проще скопировать файл конфигурации с секретами, чем обрабатывать переменные среды в конфигурации .bash_profile и конфигурации веб-сервера. Я что-то пропустил?
web-server
configuration
website
environment-variables
Аидас Бендорайтис
источник
источник
Ответы:
Автор перечисляет их рассуждения, хотя они немного несвязны. Их основной аргумент заключается в том, что в конфигурационный файл легко случайно зайти, и что файлы конфигурации имеют различные форматы и могут быть разбросаны по системе (все три из которых в лучшем случае являются посредственными аргументами для конфигурации, связанной с безопасностью, такой как токены аутентификации и учетные данные).
Исходя из моего собственного опыта, вы, по сути, получили следующие три варианта с соответствующими преимуществами и недостатками:
Храните данные в конфигурационных файлах.
При таком подходе вы должны в идеале изолировать их от самого репозитория и убедиться, что они находятся за пределами области, в которой приложение хранит свой контент.
Преимущества:
Недостатки:
Храните данные в переменных среды.
Обычно это делается путем получения списка переменных среды и значений из сценария запуска, но в некоторых случаях он может просто указывать их в командной строке перед именем программы.
Преимущества:
Недостатки
hidepidопция монтирования для/procв LInux), но они не включены по умолчанию и не защищают от атак со стороны пользователя, который владеет процессом.Используйте аргументы командной строки для передачи данных.
Серьезно, избегайте этого любой ценой, это небезопасно, и болеть в заднице трудно.
Преимущества:
Недостатки:
источник
Переменные среды будут наследоваться каждым дочерним процессом веб-сервера. Это каждая сессия, которая подключается к серверу, и каждая программа, созданная ими. Секреты будут автоматически открыты для всех этих процессов.
Если вы храните секреты в текстовых файлах, они должны быть доступны для чтения серверному процессу и, возможно, каждому дочернему процессу. Но по крайней мере программы должны пойти и найти их; они не предоставляются автоматически. Вы также можете запустить некоторые дочерние процессы под разными учетными записями и сделать секреты доступными для чтения только для этих учетных записей. Например, suEXEC делает это в Apache.
источник
MYVAR=foo /path/to/some/executable) ограничивает распространение только процессом и его дочерними элементами - и, где это необходимо, главные демоны могут выполнять очистку / сброс / изменение. среда дочерних процессов.Даже если есть некоторые компромиссы, связанные с безопасностью, которые нужно сделать, когда дело доходит до переменных или файлов среды, я не думаю, что безопасность была главной движущей силой этой рекомендации. Помните, что авторы 12factor.net также (или были также?) Разработчики Heroku PaaS. Привлечение всех к использованию переменных среды, вероятно, немного упростило их разработку. Существует так много разнообразия форматов и местоположений файлов конфигурации, и им было бы сложно поддерживать их все. Переменные среды легко сравнимы.
Не нужно много воображения, чтобы догадаться о некоторых разговорах, которые были.
1 : источник: составлен.
источник
TL; DR
Существует несколько причин для использования переменных среды вместо файлов конфигурации, но две наиболее распространенные из них, которые следует игнорировать, - это полезность конфигурации вне диапазона и улучшенное разделение между серверами, приложениями или организационными ролями. Вместо того, чтобы представлять исчерпывающий список всех возможных причин, я затрагиваю только эти две темы в своем ответе и слегка касаюсь их последствий для безопасности.
Внешняя конфигурация: отделение секретов от исходного кода
Если вы храните все свои секреты в файле конфигурации, вы должны распространять эти секреты на каждом сервере. Это либо означает проверку секретов в контроле версий вместе с вашим кодом, либо наличие полностью отдельного хранилища или механизма распространения секретов.
Шифрование ваших секретов не поможет решить эту проблему. Все, что нужно сделать, это выдвинуть проблему к одному удалению, потому что теперь вам нужно беспокоиться и об управлении ключами и их распределении!
Короче говоря, переменные среды - это подход к переносу данных для каждого сервера или приложения из исходного кода, когда вы хотите отделить разработку от операций. Это особенно важно, если вы опубликовали исходный код!
Улучшенное разделение: серверы, приложения и роли
Хотя у вас наверняка может быть файл конфигурации для хранения ваших секретов, но если вы храните секреты в исходном коде, у вас есть проблема специфичности. У вас есть отдельная ветка или хранилище для каждого набора секретов? Как вы гарантируете, что правильный набор секретов попадет на нужные серверы? Или вы уменьшаете безопасность, имея «секреты», которые везде одинаковы (или читаются везде, если у вас есть все в одном файле), и, следовательно, представляют больший риск в случае сбоя средств контроля безопасности какой-либо из систем?
Если вы хотите иметь уникальные секреты на каждом сервере или для каждого приложения, переменные среды устраняют проблему необходимости управлять множеством файлов. Если вы добавляете новый сервер, приложение или роль, вам не нужно создавать новые файлы или обновлять старые: вы просто обновляете среду рассматриваемой системы.
Прощальные мысли о безопасности
Хотя тщательное изучение безопасности ядра / памяти / файла выходит за рамки этого ответа, стоит отметить, что правильно реализованные переменные среды для системы не менее безопасны, чем «зашифрованные» секреты. В любом случае, целевая система все еще должна держать расшифрованный секрет в памяти в какой-то момент, чтобы использовать его.
Также стоит отметить, что когда значения хранятся в энергозависимой памяти на данном узле, на диске нет файла, который можно было бы скопировать и атаковать в автономном режиме. Обычно это считается преимуществом секретов в памяти, но это, конечно, не является окончательным.
Проблема переменных среды и других методов управления секретами на самом деле больше связана с компромиссами безопасности и удобства использования, чем с абсолютами. Ваш пробег может варьироваться.
источник
Лично я бы не рекомендовал устанавливать переменные окружения, так
.bashrcкак они становятся видимыми для всех процессов, запускаемых оболочкой, но устанавливать их на уровне демона / супервизора (сценарий init / rc, config systemd) так, чтобы их область действия была ограничена, где это необходимо ,Когда отдельные команды управляют операциями, переменные среды предоставляют простой интерфейс для операций, позволяющий установить среду для приложения без необходимости знать о файлах / форматах конфигурации и / или прибегать к искажению их содержимого. Это особенно верно в мультиязычных / многоуровневых настройках, где рабочие группы могут выбирать систему развертывания (ОС, процессы супервизора) в зависимости от операционных потребностей (простота развертывания, масштабируемость, безопасность и т. Д.).
Другое соображение - конвейеры CI / CD - поскольку код проходит через различные среды(т.е. dev, test / qa, staging, production) особенности среды (зоны развертывания, особенности подключения к базе данных, учетные данные, IP-адреса, доменные имена и т. д. и т. д.) лучше всего устанавливаются специальными инструментами / средами управления конфигурацией и используются приложением процессы из среды (в СУХОЙ, напиши один раз, запусти в любом месте моды). Традиционно, когда разработчики стремятся справиться с этими операционными проблемами, они, как правило, проверяют файлы конфигурации или шаблоны помимо кода, а затем заканчивают тем, что добавляют обходные пути и другие сложности, когда меняются эксплуатационные требования (например, появляются новые среды / развертывание / сайты, масштабируемость / безопасность). взвешивать,
Для производства я предпочитаю устанавливать env-vars приложения в EnvironmentFile, например
/etc/default/myapplication.conf, развертываемый с помощью управления конфигурацией, и устанавливать его для чтения толькоrootтаким образом, чтобыsystemd(или что-либо еще в этом отношении) мог порождать приложение под выделенным пользователем системы с ограниченными правами в частном порядке. группа . При поддержке выделенных групп пользователей дляopsиsudo- эти файлы по умолчанию не читаются. Это совместимо с 12 факторами, поддерживает все достоинства Dev + Ops plus и обладает всеми преимуществами достойной безопасности, позволяя при этом разработчикам / тестировщикам добавлять свои собственные файлы EnvironmentFiles в среде dev / qa / test.источник
С точки зрения разработчика, хранение данных конфигурации в переменных среды упрощает развертывание в различных средах - разработке, QA и производстве - и освобождает разработчиков от необходимости беспокоиться о развертывании неправильного файла конфигурации.
Веб-приложения Azure предоставляют возможность использовать этот шаблон, и он работает очень хорошо.
Кроме того, он хранит эти потенциально конфиденциальные данные вне контроля источников. Игнорирование этих файлов из системы управления исходным кодом на самом деле неосуществимо (по крайней мере, в .NET), поскольку в этих файлах также присутствует много необходимой стандартной конфигурации.
источник