password: '{{ env: MYUSER_PASSWORD }}'
Такое примерно?
ну это полноценная шаблонизация, я скорее имел ввиду что рядом с паролем в конфиге сказано что пароль нужно взять из строки а из инва, и название инва , --- password: inlineplainpasswod --- password: { from: inline, data: inlineplainpasswod} --- password: { from: env, env: MY_ENV_NAME_PSWD} --- password: { from: file, file: /run/secrets/pwd1} примерно так
А насколько хочется именно файл? Мне просто не очень хочется прибивать сейчас гвоздями какой-то формат файла с паролями. А вот сделать шаблонизацию с заходом в env кажется дешево и новых сущностей особо не создает. (Тут возникает та же проблема, что и с {{ hostname }}, в общем-то, но, видимо, нужно просто в документации будет прописать нюансы.)
откуда я все это взял - практика кубера, есть объекты секретов (мапа стринг - стринг), они либо в env мапятся, либо в файлы, ( плюс файлов в том что они могут обновляться без перезапуска процесса/контейнера и иметь настройку прав и овнера ) — хорошая практика это когда секреты лежат отдельно от конфигов, по причине того что у них может быть свой жизненый цикл и свои политики доступа, другое - это то что когда нужно посомтреть в конфиг или куда то его напечататать то случайно не сольешь секреты — когда приложение само умеет брать парли только из своего конига (всякое легаси) - в мире кубера делают костыли в виде того что добавляют отдельный контейнер котоырй будет делать рантайм шаблонизацию ровно перед запуском основного оприложения.
вот как в CH конфиг устроен <section> <option1_name from_env="MY_ENV_NAME_OPTION1"/> <option2_name>value2</option2_name> его ямл альтернатива section: option1_name: "@from_env": MY_ENV_NAME_OPTION1 option2_name: value2
Надо не файл, а URI который отдает плейнтекст при обращении с авторизацией. Так устроены vault, 1password.
Мысль интересная, спасибо!
Где в этих сценариях хранятся данные для авторизации? Чем-то это отличается от авторизации в etcd, чтобы стянуть оттуда конфиг?
Обсуждают сегодня