Спасибо вам за ваш контент. Год назад я еще ничего не знал про программирование. В большей степени благодаря вашему каналу я с головой погрузился в программирование, получил первую работу джуном с хорошим окладом в одной из самых известных компаний мировых. Особая благодарочка за vim. Не знаю как я раньше без него работал. Еще раз спасибо. Один из самых интересных и полезных каналов в рунете.
Да, а ещё можно хранить в разных хранилках типа Hashicorp Vault, Azure KeyVault и других системах менеджмента секретов, особенно если это не api ключи, а креды (юзернейм, пароль и т.п.). В гитхабе вроде есть возможность хранить секреты и вызывать их из кода в ci/cd пайплайнах
Недавно начал изучать Django и везде слышал, что пароли, учётки итд надо хранить в переменных окружения. Но никто об этом не рассказывал, а Вы сделали с примерами. Благодарю! Очень годный контент делаете.
Мне больше по душе хранить секюрные данные в '.env' файликах, создается два файла '.env' и '.env.example' в корене проектa, в env записываем ключи и значения а в example только ключи, .env разумеется улетает в gitignore. Теперь про то как превратить содержимое .env в переменные окружения, для этого есть библиотечка 'dotenv', к примеру в файле настроек выгружаем переменные окружения из .env файлика строчкой 'load_dotenv()', сразу же обращаемся к ним вот в таком формате BOT_TOKEN = os.getenv('BOT_TOKEN') а потому уже импортируя модуль настроек в любые файлы проекта обращаемся к значению переменой BOT_TOKEN просто по имени. Как по мне достаточно удобно и безопасно.
ibb.co/K2zpMQg Там все просто ) Но лучше, как сказали коллеги, хранить в .env файле. Кстати говоря на большом проекте таких файлов несколько. Обычно в git кладут "рыбу" с расширением txt где показывают пример .env файла. Для PROD, TEST, DEV файлы и соответственно набор переменных может быть разным. Ну и разумеется в .gitignore добавляется строчка, чтобы такие файлы не попадали в git.
А чем метод с переменными окружения лучше хранения в py-файле отдельном? Как я понимаю sh-файл и py-файл будут лежать в .gitignore. Только с пайтоновским файлом ты импортируешь модуль и используешь переменные, а с sh сначала пишешь в переменные окружения, а потом опять из программы читаешь...
@@КлинокСтальной, ошибка импорта? Так а что, если программист предусмотрел, что этого файла (пусть возьмём, что всё будет в json) может и не быть (if os.path.isfile(): json.load())... Так ещё в .gitignore можно добавлять отдельные файлы и не вижу ничего такого плохого в этом. Плюс, засорять переменные среды системы - не очень хорошая идея, имхо
@@DarkTatarin, json это уже другое, его не надо импортировать. Это не py-файл. Файлы кода всегда должны быть, а не "может есть, а может и нет". Многие ЯП, особенно компилируемые, даже не дадут тебе делать импорт модуля через if, да и в питоне это костыльно и небезопасно. И я не говорил, что надо засорять переменные среды системы. У переменных среды есть вроде бы пять уровней. На уровне системы, на уровне юзера, на уровне терминальной сессии, на уровне процесса, и еще чё то. Самый последний - это переменные среды процесса. Ты в терминале можешь перед командой написать переменные вот так: $ APP_VAR1=1 APP_VAR2=2 python3 start_app.py И эти переменные будут только у запущенной программы. И если ты в коде вызовешь что-то типа setenv("VAR1", "1"), то она будет существовать только на уровне процесса (может, дочерним процессам тоже передастся, я хз) Json тоже неплох для всяких настроек, но переменные окружения более гибки - их можно задавать разными способами. Их реально много. Сложить в файл, попросить systemd задать переменные, попросить gunicorn задать переменные. Очень гибко получается. Можно одно и то же приложение без проблем с разными значениями запускать
Ещё один из промежуточных вариантов - создание файлов .env и .env.example. Первый есть только локально и мы не помещаем его в гит, а второй нужен для декларирования переменных, необходимых проекту.
Передавать переменные через конфиг, который передается вида ./application application.conf плохо? Так можно тестировать и запускать сразу несколько конфигураций.
Xм, только малесенькая поправочка - при развороте в кибернетисе или докете, в правилах деплоя будут указаны эти переменные окружения, с паролями, и эти правила деплоя будут лежать именно в репозитории 😙 На практике - системные никто не использует, только на уровне приложения. Так что остается только хранить в репозитории конфиги для локала и теста, но без прода. А прод env есть только у одного человека.
Еще as option удобно хранить с помощью модуля keyring. Хранит пароли он в системном хранилище (keychain в случае макоси ит.д.). Имхо максимально удобный интерфейс. Сам юзаю во всех проектах на python =)
возможно расскажу и про них, хотя судя по тому коду, что вижу на code review, что присылают, там до vault еще далеко, люди непосредственно в коде хардкодят пароли и ключи, даже не в настройках
Лично я использую configParser в своих проектах и соответственно в config.ini хранятся не только API ключи, но много других настроек. Что касается безопасности, то просто добавляю этот config.ini в .gitignore😄
Отличное видео. Жаль раньше не видел- узнал много нового. Ещё одна интересная для новичка тема - не секрет, что сложность вызывает не сам Джанго и первые упражнения по нему из учебника, а начальная настройка проекта. Я имею ввиду на каком-то удалённом сервере поднять Докер контейнер, настроить связь контейнера с внешним репозиторием и внешнего репозитория со своим проектом на локальной машине. Буду очень признателен за ссылку на видео по теме( если такие есть) или если такое видео появится на канале. Спасибо за полезные видео.
Посмотрите на пакет decouple: Decouple helps you to organize your settings so that you can change parameters without having to redeploy your app. It also makes it easy for you to: - store parameters in ini or .env files; - define comprehensive default values; - properly convert values to the correct data type; - have only one configuration module to rule all your instances.
Также можно запихнуть переменные окружения в файл .env (не коммитится! Можно оставить схему этого файла в .env.example). С помощью пакета environ считывать его так: environ.Env.read_env( '.env'). После этого они доступны в коде.
на самом деле я один сейчас делаю контент и все по каналу, но говорю МЫ, потому что рассказываю в том числе о проектах нашей команды и что-то на основе нашего общего опыта внутри команды
Если уж необходимо сохранять чувствительные данные в репозитории, например в случае с IaC, есть утилита git-secret которая использует стандартное PGP шифрования
Спасибо большое за ролик! Особенно приятно видеть как вышел ролик, который я сам просил в комментариях под записью пару дней назад. Очень классно когда ютубер реально слушает аудиторию, а не просто говорит "Вы у меня самые лучшие, ваше мнение важно для меня". Ещё раз огромное спасибо, чуть попозже обязательно кину донат, потому что благодарить одними словами - на мой взгляд, просто неуважение к автору.
Здравствуйте, уважаемый! Спасибо за интересное видео. Расскажите пожалуйста, как обеспечить защиту данных от утечки на арендованном vps (прежде всего от владельцев vps)?
В текущем проекте подключение к бд храним в переменных окружения. А вот кучу всяких апи кей хранятся в таблице а в код подтягиваются функцией которая через справочник проверяет какой ключ какому пользователю можно выдать
Не рассказал одну важную вещь: после добавления новых переменных окружения, например, в "~/.bashrc" НЕ ОБЯЗАТЕЛЬНО перелогиниваться/перезагружаться, достаточно выполнить следующую команду в терминале: "source ~/.bashrc".
Существует очень распространенная конвенция dotenv и для ее реализации есть куча библиотек для всех популярных языков. Суть заключается в том, чтобы хранить конфеденциальные данные в файле .env который зачастую находится в корне проетка, и при старте программы, библиотека выгружает эти данные из файла в окружение.
Какая область видимости у переменных, добавленных через файл? Т.е. понятно, что все, что запущено в рамках этого bash процесса руками пользователя - увидит переменные, вопрос в том, могут ли какие-то демоны получить доступ к этим переменным? Тут после обновления ios выяснилось, что на мобильном очень много приложений пытаются читать все, до чего могут дотянуться, включая буфер обмена. Сразу приходит в голову то, что если переменные видны куда-то, кроме приложения, их кто-то утащит. Про продакшен с докером понятно, а как быть с компами разработчиков со всякими facebook меседжерами, и подобными пылесосами конф. данных?
В /proc//environ видны все переменные окружения, доступные запущенному процессу. Этот файл имеет права "только чтение" пользователю процесса (400). Т.е., чтобы лишние процессы не могли прочитать конфиденциальные данные из переменных окружения, нужно запускать целевой процесс от имени отдельного пользователя, под которым больше никто не входит (у него нет прав на интерактивный логин в шелл) и не запускается. Так делают все "взрослые" демоны и утилиты: postgres, nginx, ...
Товарищи. Подскажите пожалуйста, вопрос скорей всего банальный, заранее извиняюсь. Вот перенесли мы ключ в переменную окружения. отправили проект в гит (все это на компьютере на котором ведется разработка). Теперь на самом сервере клонируем данные проект, но где взять ключи? Что-то я не догнал
те любо кто получает доступ к нашему серверу, например какая то программа, она может прочитать наш ENV и отправить пароли куда то очень далеко? Интересно есть ли более безопасный метод хранения паролей?
В итоге получается, запуская скрипт мы инициализируем переменные и имеем к ним доступ на уровне окружения сессии. Почему вы тогда рекомендуете хранить их на уровне окружения программы?
Не очень понимаю вопрос. Хранение конфиденциальных ключей в переменных окружения стандартная практика. И при запуске монолита отдельно, и для ci/cd, и для контейнеров. Есть отдельные специализированные решения для хранения ключей вроде хешикорп, судя по комментам кто-то их использует
@@t0digital Я просто на основе вашего видео составляю рекомендации для разработчиков и пытаюсь для себя разобраться, на каком действительно уровне доступа создаются и хранятся переменные. В видео вы говорите, что их нужно создавать на 4м уровне окружения программы. Однако запустив скрипт с экспортом переменных, мы по факту инициализировали их на 3м уровне окружения сессии. Получается правильно говорить, что вся конфиденциальная информация хранится на 3м уровне в переменных окружения сессии.
@@alw-3052 setenv.sh установит переменные окружения на уровне сессии, да. Я вроде не говорил в видео, что надо обязательно на 4м уровне создавать переменные окружения. Тут всё зависит от того, как будет запускаться приложение. Если без докера, то скорее всего через systemd, там переменные окружения могут прописываться в файле настройки systemd сервиса и как они там будут работать - для какой-то systemd сессии или для запускаемого файла я даже не знаю. Скорее всего для файла, то есть на 4м уровне, но это не принципиально. Мой рассказ про уровни переменных окружения это просто для понимания где и как могут задаваться эти переменные окружения, не более того.
Пролистал видео, не увидел решений типа HashCorp Vault/AWS Secrets Manager. В этом случае переменные никогда не попадают на сервер в виде файлов/переменных окружения. что в целом здорово. И в случае Secrets Manager, не нужен никакой токен для доступа, просто дается к секрету доступ с конкретного сервера(или любой другой вариант настройки доступный на Амазоне).
@@oleksiilobodiev9446 yeah, I know. But anyway, this approach wasn't mentioned by author. I think it's separated approach(together with Secrets Manager, of course there are some difference between those services)
Где-то я далеко от темы или сейчас был просто наглядный пример забивания переменных систему локально? Просто я таким начал заниматься в самом начале знакомства с linux используя aliasы. А к примеру весь код хранится в репе, из репы он идёт в teamcity агент и от туда деплоится на серверы как в таком случае хранить пасворды и прочие api?
Спасибо за видео! Узнал, как переменные окружения работают! Я раньше думал, что переменные окружения это только path! Такой вопрос: я пол-года назад загрузил в git проект, где в python коде хранился ключ. И мне предложил git поставить git guardian. Может ли как-то git guardian тоже помочь в такой ситуации? Спасибо!
Я бы рекомендовал systemd вместо supervisord coreos.com/os/docs/latest/using-environment-variables-in-systemd-units.html Можно сделать файл просто ключ=значение, его будет читать systemd, и его же может читать shell script. Для systemd shell скрипт будет не нужен, просто для себя, что-то в консоли запустить
Объясните почему не получается получить переменную окружения когда запускаю PHP сайт посредством Apache2 ? Что нужно сделать для получения этих переменных? Когда запускаю файл php с командной строки все переменные видны.
Спасибо за полезный контент. У меня вопрос. Как правильно распространять такие шелл скрипты внутри команды?Допустим есть есть скриптик, где прописаны креденшилы для базы данных. И нужно чтобы человек получил его для того, чтобы он мог у себя локально подключатся к бд. Как в таком случае безопасно предоставить доступ?
Можно сделать env файл с примером заполнения, и обязательно прописать в README файле полную конфигурацию, то есть что где надо заполнить, чтобы запустить проект. Добавилась новая переменная, внесли ее в example env файл, добавили сразу в документацию README
@@swimmwatch упаковать в шифрованный архив. Пароль от архива - обязательно по другому каналу связи. Т.е. если шлёшь архив в email, то пароль от него - в SMS
А Вам не кажется, что 2 переменная, которая в .bash_... файле, это тоже переменная сеанса, а не юзера. Думаю что уровень юзера не должен зависеть от выбора шела. Если не прав, поправьте плиз.
Спасибо за крутой ролик, как всегда - лайк) Плохой ли практикой является хранение ключей в базе данных, в специальной модели конфигов? Знаю, что это точно удобнее для людей, для которых делается сервис, которые, возможно, никогда не узнают о существовании переменных окружения)
День добрый, мне очень понравился выпуск. Как всегда доходчиво и по теме. Есть одно обстоятельство. Я не смог применить замечательный принцип использования переменного окружения. Если бы речь шла о локальной машине или локально развернутом докере, то все хорошо, но я деплою свой проект непосредственно в heroku.com и все что я могу вписать, в качестве инициализации в процессе развертывания, находится в репозитории самого сервиса, либо github. Хранить в таком виде ключи не очень хорошо. Если у Вас есть опыт в подобных случаях, подскажите направление? Спасибо большое за такие публикации.
@@t0digital Возможно. Но в bash проблем не встречал. Zsh, который с недавних пор стал по умолчанию в manjaro и поэтому пришлось им попользоваться (для ознакомления, хотя бы) - у меня в принципе странно работал. Многие переменные окружения перечитывались с ошибками или вовсе не читались. Часть приложений и вовсе перестала запускаться. Вернулся на bash - проблем нет.
Видел в какой-то статье в интернете, и сам пользуюсь, чтобы переменные с .bashrc применились, после сохранения файла исполняю source .bashrc, чтобы не перезаходить.
Было бы здорово, видеть не просто код, но и схемы. Например, 4 уровня можно было отобразить схематично. И как пред-преджун скажу, что действия с vim были совершено непонятны. 1. Где документ создавался, в какой директории, что за export? 2. Если приложение запускается на облачном сервисе для запуска скриптов, там тоже есть переменные окружения или для этого нужно сервер арендовать?
@@fedor_ado, ну вот так все кто записывает видео и думают наверное. Куда мне до тебя, Фёдор... ты же наверное любого незнакомого предмета касаешься и уже понимаешь как он собран. Тебе бы авиационные или ракетные двигатели собирать.
@@ivanl7786 ты пост свой почитай, там у тебя вся вселенная собрана. Если он на твои растекания мысли по древу отвечать будет - проще тебя на курсы компьютерной грамотности отправить. Формулируй или гугли усиленно, в итоге у тебя сформируется представление о предмете. Без обид.
![Felix "Unfair" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/Oswujxm2Ag0/mqdefault.jpg)
Мой курс «Хардкорная веб-разработка» - course.to.digital
Вжух!
Вот побольше таких best practices
И музыка отличная
Спасибо!
Знаете, музыка похожа на музыку из торгового дома из Вай Сити
Прекрасно! Спасибо огромное. На старости лет, просто для себя, учу Питон (в детстве программировал на Паскале). А началось все с вашего канала. )
Рад, что полезно! Спасибо!
Как говорится, пришел по зову сердца
Четкий канал, без кривляний, тупых приколов. Только полезная и доходчивая информация, без лишней воды.
Спасибооо!
Спасибо, что прислушиваешься к запросам в комментариях! То что просил - получил 🥳 Респект.
Предыдущее видео по Джанго тоже доставило. 👍🏻
Спасибо :)!
Спасибо вам за ваш контент. Год назад я еще ничего не знал про программирование. В большей степени благодаря вашему каналу я с головой погрузился в программирование, получил первую работу джуном с хорошим окладом в одной из самых известных компаний мировых. Особая благодарочка за vim. Не знаю как я раньше без него работал. Еще раз спасибо. Один из самых интересных и полезных каналов в рунете.
Йеее, спасибо! Очень рад за вас!
Да, а ещё можно хранить в разных хранилках типа Hashicorp Vault, Azure KeyVault и других системах менеджмента секретов, особенно если это не api ключи, а креды (юзернейм, пароль и т.п.). В гитхабе вроде есть возможность хранить секреты и вызывать их из кода в ci/cd пайплайнах
Единственный нормальный коммент) Хорошей реализацией является Hashicop Vault
а дак вот зачем нужен Vault..., до сего момента я ключи в postman хранил
Недавно начал изучать Django и везде слышал, что пароли, учётки итд надо хранить в переменных окружения. Но никто об этом не рассказывал, а Вы сделали с примерами. Благодарю! Очень годный контент делаете.
Спасибо тебе! Если что-то нужно узнать по python, то в начале смотрю на твоем канале. И чаще всего нахожу. Да еще в такой понятной и доступной форме.
Спасибооо!
Лайк не глядя, я в натуре думаю что ты лучше чем некоторые блогер "программист"и
Спасибо:)!
Умные мысли в слух под красивую спокойную музыку. Спасибо!
Спасибо!
Классные видео, с удовольствием все время смотрят у меня в семье парни 12 лет.
Мне больше по душе хранить секюрные данные в '.env' файликах, создается два файла '.env' и '.env.example' в корене проектa, в env записываем ключи и значения а в example только ключи, .env разумеется улетает в gitignore. Теперь про то как превратить содержимое .env в переменные окружения, для этого есть библиотечка 'dotenv', к примеру в файле настроек выгружаем переменные окружения из .env файлика строчкой 'load_dotenv()', сразу же обращаемся к ним вот в таком формате BOT_TOKEN = os.getenv('BOT_TOKEN') а потому уже импортируя модуль настроек в любые файлы проекта обращаемся к значению переменой BOT_TOKEN просто по имени. Как по мне достаточно удобно и безопасно.
Супер годнота! Спасибо за контент , не останавливайся :)
Будем фигачить дальше!
Спасибо что ты есть!
Спасибо за классный урок) Как раз изучаю Flask и был вопрос по хранению паролей и настроек проекта, теперь он решен)
Отлично!
Круто, оч полезно, спасибо!
Весьма информативно, спасибо за ролик!
Очень полезно и хорошо рассказано!)
Спасибо!
Спасибо! Очень хотелось бы короткий гайд по работе с такими переменными в PyCharm. Подозреваю, что там есть какая-то автоматизация этих процессов.
ibb.co/K2zpMQg Там все просто ) Но лучше, как сказали коллеги, хранить в .env файле. Кстати говоря на большом проекте таких файлов несколько. Обычно в git кладут "рыбу" с расширением txt где показывают пример .env файла. Для PROD, TEST, DEV файлы и соответственно набор переменных может быть разным. Ну и разумеется в .gitignore добавляется строчка, чтобы такие файлы не попадали в git.
Очень понравилось, полезная информация, спасибо огромное, очень ждал
А чем метод с переменными окружения лучше хранения в py-файле отдельном? Как я понимаю sh-файл и py-файл будут лежать в .gitignore. Только с пайтоновским файлом ты импортируешь модуль и используешь переменные, а с sh сначала пишешь в переменные окружения, а потом опять из программы читаешь...
Я подозреваю что единственное преимущество это то что в докер проще будет прокинуть переменную окружения чем файл
Если .py файла не будет, то будет ошибка импорта. Всё таки это раз это код, то теперь это часть проекта, которую нельзя добавлять в .gitignore.
@@КлинокСтальной, ошибка импорта? Так а что, если программист предусмотрел, что этого файла (пусть возьмём, что всё будет в json) может и не быть (if os.path.isfile(): json.load())...
Так ещё в .gitignore можно добавлять отдельные файлы и не вижу ничего такого плохого в этом. Плюс, засорять переменные среды системы - не очень хорошая идея, имхо
@@DarkTatarin, json это уже другое, его не надо импортировать. Это не py-файл. Файлы кода всегда должны быть, а не "может есть, а может и нет". Многие ЯП, особенно компилируемые, даже не дадут тебе делать импорт модуля через if, да и в питоне это костыльно и небезопасно.
И я не говорил, что надо засорять переменные среды системы. У переменных среды есть вроде бы пять уровней. На уровне системы, на уровне юзера, на уровне терминальной сессии, на уровне процесса, и еще чё то. Самый последний - это переменные среды процесса. Ты в терминале можешь перед командой написать переменные вот так:
$ APP_VAR1=1 APP_VAR2=2 python3 start_app.py
И эти переменные будут только у запущенной программы.
И если ты в коде вызовешь что-то типа setenv("VAR1", "1"), то она будет существовать только на уровне процесса (может, дочерним процессам тоже передастся, я хз)
Json тоже неплох для всяких настроек, но переменные окружения более гибки - их можно задавать разными способами. Их реально много. Сложить в файл, попросить systemd задать переменные, попросить gunicorn задать переменные. Очень гибко получается. Можно одно и то же приложение без проблем с разными значениями запускать
Ооооо огромное спасибо! Как раз просил на эту тему ролик
Концерт по заявкам:)!
Спасибо большое!!! Как раз то, что нужно!
Спасибо за урок!)
Спасибо!
Знал, канеш -- но тут разложили по полочкам, можно рекомендовать начинающим коллегам.
Спасибо за видео 👍
Ещё один из промежуточных вариантов - создание файлов .env и .env.example. Первый есть только локально и мы не помещаем его в гит, а второй нужен для декларирования переменных, необходимых проекту.
Да. И ещё ридми всегда очень кстати
Полезно, большое спасибо!
Рад, что полезно :)!
Спасибо за видео
Спасибо, было полезно. Как и всегда впрочем)
Каждый день новые видосы, я попал в рай?
Сделаем и этот мир райским:)!
Спасибо! Было познавательно
рад, что полезно!
То, что надо. Спасибо!
Спасибо большое! Очень помогли!
Было бы замечательно сделать видос по доккеру и его настройке)
думаю, сделаю
Передавать переменные через конфиг, который передается вида ./application application.conf плохо?
Так можно тестировать и запускать сразу несколько конфигураций.
Xм, только малесенькая поправочка - при развороте в кибернетисе или докете, в правилах деплоя будут указаны эти переменные окружения, с паролями, и эти правила деплоя будут лежать именно в репозитории 😙
На практике - системные никто не использует, только на уровне приложения. Так что остается только хранить в репозитории конфиги для локала и теста, но без прода. А прод env есть только у одного человека.
Еще as option удобно хранить с помощью модуля keyring. Хранит пароли он в системном хранилище (keychain в случае макоси ит.д.). Имхо максимально удобный интерфейс. Сам юзаю во всех проектах на python =)
Спасибо, очень жду видео по эксепшенам
Скоро будет
Просьба сделать видос про тестирование в django!!!
Будет такой видос:)
Ожидал услышать что-то про vault и системы хранения паролей...
возможно расскажу и про них, хотя судя по тому коду, что вижу на code review, что присылают, там до vault еще далеко, люди непосредственно в коде хардкодят пароли и ключи, даже не в настройках
@@t0digital будем ждать!
Круто. Спасибо большое
Дружище, а как то можно их получать из Маковского key-chain? И сразу второй вопрос, а есть ли библиотека на Python взаимодействующая с key-chain?
Лично я использую configParser в своих проектах и соответственно в config.ini хранятся не только API ключи, но много других настроек. Что касается безопасности, то просто добавляю этот config.ini в .gitignore😄
Отличное видео. Жаль раньше не видел- узнал много нового. Ещё одна интересная для новичка тема - не секрет, что сложность вызывает не сам Джанго и первые упражнения по нему из учебника, а начальная настройка проекта. Я имею ввиду на каком-то удалённом сервере поднять Докер контейнер, настроить связь контейнера с внешним репозиторием и внешнего репозитория со своим проектом на локальной машине. Буду очень признателен за ссылку на видео по теме( если такие есть) или если такое видео появится на канале. Спасибо за полезные видео.
Посмотрите на пакет decouple:
Decouple helps you to organize your settings so that you can change parameters without having to redeploy your app.
It also makes it easy for you to:
- store parameters in ini or .env files;
- define comprehensive default values;
- properly convert values to the correct data type;
- have only one configuration module to rule all your instances.
Также можно запихнуть переменные окружения в файл .env (не коммитится! Можно оставить схему этого файла в .env.example). С помощью пакета environ считывать его так: environ.Env.read_env( '.env'). После этого они доступны в коде.
Полезное видео, спасибо!
"Поддержать нас". Кто входит в команду? Очень интересно, кто создаёт такой прекрасный и полезный материал))
на самом деле я один сейчас делаю контент и все по каналу, но говорю МЫ, потому что рассказываю в том числе о проектах нашей команды и что-то на основе нашего общего опыта внутри команды
По старинке пользуюсь конфигурационными файлами, и норм
Не безопасно
Спасибо, было полезно
Если уж необходимо сохранять чувствительные данные в репозитории, например в случае с IaC, есть утилита git-secret которая использует стандартное PGP шифрования
Звук - бомба.
Музыка - лишняя.
Cheers! ✌
Спасибо большое за ролик! Особенно приятно видеть как вышел ролик, который я сам просил в комментариях под записью пару дней назад. Очень классно когда ютубер реально слушает аудиторию, а не просто говорит "Вы у меня самые лучшие, ваше мнение важно для меня". Ещё раз огромное спасибо, чуть попозже обязательно кину донат, потому что благодарить одними словами - на мой взгляд, просто неуважение к автору.
Здравствуйте, уважаемый! Спасибо за интересное видео. Расскажите пожалуйста, как обеспечить защиту данных от утечки на арендованном vps (прежде всего от владельцев vps)?
Аренда VPS по сути подразумевает доверие владельцам VPS. Не думаю, что стоит париться об этом, если арендуете машину не у ноунеймов
В текущем проекте подключение к бд храним в переменных окружения. А вот кучу всяких апи кей хранятся в таблице а в код подтягиваются функцией которая через справочник проверяет какой ключ какому пользователю можно выдать
Здорово)
Не рассказал одну важную вещь: после добавления новых переменных окружения, например, в "~/.bashrc" НЕ ОБЯЗАТЕЛЬНО перелогиниваться/перезагружаться, достаточно выполнить следующую команду в терминале: "source ~/.bashrc".
Или "exec bash"
Существует очень распространенная конвенция dotenv и для ее реализации есть куча библиотек для всех популярных языков. Суть заключается в том, чтобы хранить конфеденциальные данные в файле .env который зачастую находится в корне проетка, и при старте программы, библиотека выгружает эти данные из файла в окружение.
Спасибо! А немножко про Vault?
Есть замечательная штука для того, чтобы можно было держать ключи в гите, Mozilla SOPS называется) ключи от него могут быть у разрабов и в CI
Интересно было бы дополнить материал системами типа Vault.
Возможно сделаю, спасибо
Отличное видео.
спасибо!
Какая область видимости у переменных, добавленных через файл? Т.е. понятно, что все, что запущено в рамках этого bash процесса руками пользователя - увидит переменные, вопрос в том, могут ли какие-то демоны получить доступ к этим переменным? Тут после обновления ios выяснилось, что на мобильном очень много приложений пытаются читать все, до чего могут дотянуться, включая буфер обмена. Сразу приходит в голову то, что если переменные видны куда-то, кроме приложения, их кто-то утащит. Про продакшен с докером понятно, а как быть с компами разработчиков со всякими facebook меседжерами, и подобными пылесосами конф. данных?
В /proc//environ видны все переменные окружения, доступные запущенному процессу. Этот файл имеет права "только чтение" пользователю процесса (400). Т.е., чтобы лишние процессы не могли прочитать конфиденциальные данные из переменных окружения, нужно запускать целевой процесс от имени отдельного пользователя, под которым больше никто не входит (у него нет прав на интерактивный логин в шелл) и не запускается. Так делают все "взрослые" демоны и утилиты: postgres, nginx, ...
7:36
пэсс - pass - проходить
па(тот самый звук) - path - путь
Супер!
Был бы здорово если бы вы сделали видео про асинхронность в python. Контен огонь)
Спасибо! Про асинхронность будет!
Как говорится не по колокольчику, а по зову сердца)
Хахах :) спасибо!
Товарищи. Подскажите пожалуйста, вопрос скорей всего банальный, заранее извиняюсь. Вот перенесли мы ключ в переменную окружения. отправили проект в гит (все это на компьютере на котором ведется разработка). Теперь на самом сервере клонируем данные проект, но где взять ключи? Что-то я не догнал
те любо кто получает доступ к нашему серверу, например какая то программа, она может прочитать наш ENV и отправить пароли куда то очень далеко? Интересно есть ли более безопасный метод хранения паролей?
Спасибо.
Расскажи про pipenv/virtualenv ещё
Отличный видос! А что вы скажите на счёт git-crypt?
В итоге получается, запуская скрипт мы инициализируем переменные и имеем к ним доступ на уровне окружения сессии. Почему вы тогда рекомендуете хранить их на уровне окружения программы?
Не очень понимаю вопрос. Хранение конфиденциальных ключей в переменных окружения стандартная практика. И при запуске монолита отдельно, и для ci/cd, и для контейнеров. Есть отдельные специализированные решения для хранения ключей вроде хешикорп, судя по комментам кто-то их использует
@@t0digital Я просто на основе вашего видео составляю рекомендации для разработчиков и пытаюсь для себя разобраться, на каком действительно уровне доступа создаются и хранятся переменные.
В видео вы говорите, что их нужно создавать на 4м уровне окружения программы. Однако запустив скрипт с экспортом переменных, мы по факту инициализировали их на 3м уровне окружения сессии.
Получается правильно говорить, что вся конфиденциальная информация хранится на 3м уровне в переменных окружения сессии.
@@alw-3052 setenv.sh установит переменные окружения на уровне сессии, да. Я вроде не говорил в видео, что надо обязательно на 4м уровне создавать переменные окружения. Тут всё зависит от того, как будет запускаться приложение. Если без докера, то скорее всего через systemd, там переменные окружения могут прописываться в файле настройки systemd сервиса и как они там будут работать - для какой-то systemd сессии или для запускаемого файла я даже не знаю. Скорее всего для файла, то есть на 4м уровне, но это не принципиально.
Мой рассказ про уровни переменных окружения это просто для понимания где и как могут задаваться эти переменные окружения, не более того.
@@t0digital теперь разобрался. Спасибо! Очень полезное видео.
Пролистал видео, не увидел решений типа HashCorp Vault/AWS Secrets Manager. В этом случае переменные никогда не попадают на сервер в виде файлов/переменных окружения. что в целом здорово. И в случае Secrets Manager, не нужен никакой токен для доступа, просто дается к секрету доступ с конкретного сервера(или любой другой вариант настройки доступный на Амазоне).
HashiCorp Vault have some config file for this task
@@oleksiilobodiev9446 yeah, I know. But anyway, this approach wasn't mentioned by author. I think it's separated approach(together with Secrets Manager, of course there are some difference between those services)
Применить изменения в кофиге без перезапуска сессии и перезагрузки: "source ~/.zshenv" , "source ~/.bashrc"
Да, можно так
Для того что бы не перезагружать систему после добавления новых переменных окружения, можно использовать команду 'source'
Возник небольшой вопрос. Есть такая либка для питона как keyring. Было бы интересно узнать Ваше мнение по поводу необходимости этой либки.
Спасибо!
Хм, а чем не устраивает вариант с использованием пакета python-dotenv? Вроде удобнее
Где-то я далеко от темы или сейчас был просто наглядный пример забивания переменных систему локально? Просто я таким начал заниматься в самом начале знакомства с linux используя aliasы. А к примеру весь код хранится в репе, из репы он идёт в teamcity агент и от туда деплоится на серверы как в таком случае хранить пасворды и прочие api?
Спасибо за видео! Узнал, как переменные окружения работают! Я раньше думал, что переменные окружения это только path! Такой вопрос: я пол-года назад загрузил в git проект, где в python коде хранился ключ. И мне предложил git поставить git guardian. Может ли как-то git guardian тоже помочь в такой ситуации? Спасибо!
Почему про dotenv не рассказал?
Хороший подход, а как в supervisord засунуть список переменных из файла не подскажете?
Я бы рекомендовал systemd вместо supervisord coreos.com/os/docs/latest/using-environment-variables-in-systemd-units.html
Можно сделать файл просто ключ=значение, его будет читать systemd, и его же может читать shell script. Для systemd shell скрипт будет не нужен, просто для себя, что-то в консоли запустить
Хороший канал
Спасибо!
Объясните почему не получается получить переменную окружения когда запускаю PHP сайт посредством Apache2 ?
Что нужно сделать для получения этих переменных?
Когда запускаю файл php с командной строки все переменные видны.
Ничего не понял, но очень интересно
Спасибо за полезный контент. У меня вопрос. Как правильно распространять такие шелл скрипты внутри команды?Допустим есть есть скриптик, где прописаны креденшилы для базы данных. И нужно чтобы человек получил его для того, чтобы он мог у себя локально подключатся к бд. Как в таком случае безопасно предоставить доступ?
Можно сделать env файл с примером заполнения, и обязательно прописать в README файле полную конфигурацию, то есть что где надо заполнить, чтобы запустить проект. Добавилась новая переменная, внесли ее в example env файл, добавили сразу в документацию README
@@t0digital А как передавать этот файл безопасно ?
@@swimmwatch упаковать в шифрованный архив. Пароль от архива - обязательно по другому каналу связи. Т.е. если шлёшь архив в email, то пароль от него - в SMS
Подписался на boosty
Юхууу, спасибо!
Не глядя, лайк!
А Вам не кажется, что 2 переменная, которая в .bash_... файле, это тоже переменная сеанса, а не юзера. Думаю что уровень юзера не должен зависеть от выбора шела. Если не прав, поправьте плиз.
Я просто создавал пайтон файл в котором определял переменные, и импортировал в конфиг
Что за шрифт?! Очень классный
Скорее всего Monaco
Спасибо за крутой ролик, как всегда - лайк)
Плохой ли практикой является хранение ключей в базе данных, в специальной модели конфигов? Знаю, что это точно удобнее для людей, для которых делается сервис, которые, возможно, никогда не узнают о существовании переменных окружения)
День добрый, мне очень понравился выпуск. Как всегда доходчиво и по теме.
Есть одно обстоятельство.
Я не смог применить замечательный принцип использования переменного окружения. Если бы речь шла о локальной машине или локально развернутом докере, то все хорошо, но я деплою свой проект непосредственно в heroku.com и все что я могу вписать, в качестве инициализации в процессе развертывания, находится в репозитории самого сервиса, либо github. Хранить в таком виде ключи не очень хорошо. Если у Вас есть опыт в подобных случаях, подскажите направление? Спасибо большое за такие публикации.
Перелогиниваться не обязательно. Можно сделать:
$ source path_to_file
Переменные перечитаются из нужного файла
Это не всегда работает корректно, зависит от настроек/плагинов в используемом шелле
@@t0digital Возможно. Но в bash проблем не встречал. Zsh, который с недавних пор стал по умолчанию в manjaro и поэтому пришлось им попользоваться (для ознакомления, хотя бы) - у меня в принципе странно работал. Многие переменные окружения перечитывались с ошибками или вовсе не читались. Часть приложений и вовсе перестала запускаться. Вернулся на bash - проблем нет.
спасибо)
Видел в какой-то статье в интернете, и сам пользуюсь, чтобы переменные с .bashrc применились, после сохранения файла исполняю source .bashrc, чтобы не перезаходить.
Можно, но может приводить к ошибкам, там может быть много всего понаписано корявенького)
Диджитализируй! Окей, спасибо, потому и написал, узнать, ок или нет)
Было бы здорово, видеть не просто код, но и схемы. Например, 4 уровня можно было отобразить схематично.
И как пред-преджун скажу, что действия с vim были совершено непонятны.
1. Где документ создавался, в какой директории, что за export? 2. Если приложение запускается на облачном сервисе для запуска скриптов, там тоже есть переменные окружения или для этого нужно сервер арендовать?
У тебя в огороде бузина - в Киеве дядька. Арендуй сервер, сразу всё поймёшь и гуглить не надо будет. :))
@@fedor_ado, ну вот так все кто записывает видео и думают наверное. Куда мне до тебя, Фёдор... ты же наверное любого незнакомого предмета касаешься и уже понимаешь как он собран. Тебе бы авиационные или ракетные двигатели собирать.
@@ivanl7786 ты пост свой почитай, там у тебя вся вселенная собрана. Если он на твои растекания мысли по древу отвечать будет - проще тебя на курсы компьютерной грамотности отправить. Формулируй или гугли усиленно, в итоге у тебя сформируется представление о предмете. Без обид.
Интересно вот Jenkins берет из git python код проекта и хочет погонять его в docker контейнере. Откуда брать .env файл тогда?
музыка зачет