Комментарии 28
Спасибо за пост. Не нашел причины замены ansible-vault на новую консольную утилиту.
password: !vault |
$ANSIBLE_VAULT;1.1;AES256
61373536353963313739366536643661313861663266373130373730666634343337356536333664
3365393033623439356364663537353365386464623836640a356464633264626330383232353362
63613135373638393665663962303530323061376432333931306161303966633338303565666337
6465393837636665300a633732313730626265636538363339383237306264633830653665343639
30353863633137313866393566643661323536633666343837623130363966613363373962343630
34386234633236363363326436666630643937313630346230386538613735366431363934316364
37346337323833333165386534353432386663343465333836643131643237313262386634396534
38316630356530626430316238383364376561393637363262613666373836346262666536613164
66316638343162626631623535323666643863303231396432666365626536393062386531623165
63613934323836303536613532623864303839313038336232616134626433353166383837643165
643439363835643731316238316439633039
ansible-vault encrypt_string "SuperSecretPassword" --name "password" --vault-password-file=~/.vault_passwordВ статье же речь идет о том, как обрабатывается типичный `secrets.yaml` с которым работа происходит напрямую — шифруется весь файл, а не отдельные значения.
Я из "дано" не понял юзкейса. Можете развернуть мысль, как и когда именно применяется данная утилита в вашем пайплайне? Т.е. описать пайплайн
Кому-то просто не хочется в какой-то джобе ставить питон с анисблом ради банального decrypt.
А паскаль хочется? Ну и если уже ключевые куски алгоритма в Ansible найдены, то весь Ansible уже и не нужен? Т.е., выдираем нужные куски, делаем из них свой маленький питоновский пакет с консольной точкой входа, и получается тоже вроде как консольная утилита (типа pip.exe, mypy.exe) размером 100 килобайт, кстати. Ну, да, питон нужен...
Так паскаль не ставится — билд процесс отдельно. Замечание с запаковкой python в самораспаковывающийся исполняемый файл — да, возможно, но все равно зачем ?
Паскаль вам в пайплайн ставить не нужно, а нужно только бинарь.
Однако… Этот бинарь кто-то должен собирать, мейнтенить, тестировать и выкладывать в хранилище артефактов. Минимум ещё один git-репозиторий, ещё один pipeline/workflow/job, плюс нестандартная зависимость.
Короче, не убеждает.
К сожалению, в моём случае конкретика вся под NDA, но в целом история очень простая: все внедряемые системы обязаны иметь поддержку RBAC для целей контроля доступа и аудита. Соответственно, сборочному конвейеру требуются креды для хранилища артефактов, анализатора качества кода, статического анализатора, ишью-трекера, вики, бота для мессенджера, почты… В общем, всего этого слишком много для того, чтобы в открытом виде складывать в переменные гитлаба, в которых до сих пор не завезли толковый RBAC — вот и решил посмотреть, что можно сделать в варианте «прочесть секрет без питона и ансибла».
Побуду адвокатом дьявола — а в чем практическая польза (кроме «я сделал, потому что могу»)?
Как ускорились пайплайны с учетом уменьшения размера образов?
Ну, насчёт всего ansible понятно. А python-то на агентах есть?
Очень странный метод.
Хинт: gitlab поддерживает file variables. Делаете одну переменную вида
export FOO=foo
export BAR=bar
export FOOBAR=foobarи потом его source.
таким образом можно десятки килобайт прокачивать и не взрываться мозгом.
Это немасштабируемо. Когда нужен один секрет или два — менеджить это можно, когда их сотня-другая? Тогда и возникает желание их подставить в гит.
Дополнительно — переменные гитлаба и их изменение никак не отслеживается. Возможно, где-то есть логи аудита самого гитлаба, но обычным смертным они недоступны. А если хранить переменные в самом гите — вот тебе и аудит, и история изменения. Только шифрование надежное нужно
Это масштабируемо в разумных пределах. Если же вы хотите человеческий аудит доступа к секретам, то берите hashicorp'овый vault, он для этого и сделан.
Все равно не решается проблема попадания секретов в vault.
Vault — это хранилка. А не менеджилка секретов.
Если же вы хотите человеческий аудит доступа к секретам
Ещё раз — не аудит доступа, а аудит изменения. Как бы почти одно и тоже, но по факту — очень разные вещи
Да, я в курсе, что ты этим хочешь доказать? Что не нужно какое-то промежуточное решение между gitlab переменными/ansible vault и hashicorp vault?
Hashicorp Vault — неплохое решение, с этим никто не спорит. И на определенном уровне зрелости команд и процессов он становится необходим. Но до этого момента вполне можно пользоваться sops / ansible-vault :/
Соб-но, настоящая статья и является примером того, как несложно напилить полезный инструментарий для этого.
Для standalone ansible-vault, кстати, есть уже неплохая реализация:
https://github.com/marcobellaccini/nanvault
Не большая экзотика, чем Pascal в 2021. Насчет "не умеет в Windows" — странная претензия от создателя "пользователи Windows должны страдать". :) Умеет (или не умеет — вопрос точки зрения) это решение точно также, как и Ansible, собственно.
Мой пойнт был лишь в том, что странно начинать пилить свой собственный велосипед почти с нуля при наличии уже готовых и неплохо ездящих моделей, которые решают ту же задачу.
Ansible-vault decrypt: обходимся без Ansible