Сьогодні хотів знову зачепити тему роботи з «секретами» при розробці проєктів, а саме: з паролями, API-ключами, токенами тощо. Мені особисто дуже муляє око, коли вони у відкритому вигляді на диску лежать, навіть якщо цей файл не потрапляє в ґіт.
Ну, власне, тому я їх відкрито вже давно й не тримаю. Колись уже розповідав, як використовую 1Password для підписування комітів та роботи з Ansible 💻. А сьогодні хотів трохи написати про
.env-файли.Проблема з ними якраз і полягає в тому, що вони в ґіті не зберігаються. Тобто щоразу, як зробив чистий клон проєкту, треба цей файл руками створювати. Звісно, можна покласти
.env.example, в якому принаймні назви всіх змінних будуть, але спробуй ще згадай, де і як ти ті ключі та токени отримував. У мене їх десятки, всі з різними правами й скоупами, і я швидко починав у цьому губитися.Тому нині мої
.env на вигляд зазвичай приблизно отакі:GITHUB_TOKEN="op://Work/repo-name/wrxqfrltnqlzgako6zx6fjak6m/GITHUB_TOKEN"
TF_VAR_github_app_private_key="op://Work/repo-name/private key"
TF_VAR_crowdin_token="op://Work/repo-name/CROWDIN_PERSONAL_TOKEN/value"
TF_VAR_discord_webhook="op://Work/repo-name/DISCORD_WEBHOOK_URL/value"
TF_VAR_rclone_config="op://Work/repo-name/RCLONE_CONFIG/value"
Вочевидь, тут нема жодних секретів, які не можна було б зберігати в системі контролю версій, бо значення змінних — це просто посилання на конкретні записи 1Password. До того ж не треба взагалі нічого міняти: зробив клон — і все одразу працює. Єдиний мінус полягає в тому, що тепер замість умовного
terraform apply доводиться писатиop run --env-file=".env" -- terraform apply
Я, звісно, махав це щоразу руками друкувати, тому використовую
just, про який теж неодноразово вже згадував.А нещодавно дізнався про ще одну нову альтернативну фічу 1Password (наразі бета). Тепер вони дозволяють створювати різні оточення зі своїми наборами секретів прямо в їхній програмі. І потім такі оточення можна монтувати за певним шляхом як
.env-файл. Але! Файлу насправді нема 🙂 Замість того, щоб записувати ці всі секрети відкрито на диск, вони просто створюють іменований жолоб (pipe по-вашому): щойно хтось намагається прочитати звідти дані, 1Password просить вас авторизувати цей запит і передає значення прямо в програму! Ніби нічого складного, але доволі креативний розвʼязок до проблеми.Переваги підходу в тому, що ви запускаєте всі свої тулзи як зазвичай — без жодних
op run. А головний мінус для мене: наразі все ж не дуже зручно цим керувати. До того ж після клонування треба заходити й монтувати це оточення в потрібну теку. Тож для себе я вирішив лишитися на попередньому варіанті.Взагалі подобається, що 1Password не стоїть на місці й постійно розвивається. Але не подобається, що вони й так не дешеві, а скоро ще й піднімають вартість передплати 🥲