Где и как лучше хранить конфиденциальные данные для разворачивания проекта?

Question

[Сергей Соколов]

Код проекта хранится в приватном git репо. Ключи и пароли от сторонних сервисов, с которыми проект взаимодействует (AWS, Robokassa, Paypal, Stripe), лежат вне репо – пока что у меня на локальном ноуте в 1Password, например. В проекте все приватные данные оказываются в переменных окружения, и оттуда берутся скриптами. Для Laravel это или через создание .env.php в корне проекта, или через конфиги веб-сервера или параметры при запуске docker-контейнера.

Во время разворачивания ещё требуются SSH-ключи и ключи от DigitalOcean.

Задачи сейчас:

1. При нулевом ручном вмешательстве разворачивать новые серверы с проектом
   
2. Привлечь сторонних девелоперов, которым production-ключи не показывать. Для разработки/тестирования есть отдельный набор ключей.
   

Вопрос: как и где лучше хранить и обновлять ключи, и как их вытаскивать при разворачивании проекта, не давая доступа к ним сторонних разработчиков? Т.е., видимо, должна быть одна точка авторизации - например, при запуске скрипта, которая открывает доступ к некому хранилищу с ключами и разворачивает новый сервер с проектом. Сами ключи хочется держать отдельно от скриптов деплоя.

Answer 1

[skrimafonolog]

Hashicorp Vault
или Ansible Vault

Несмотря на совпадение названий - это принципиально разные вещи.

Answer 2

[redakoc]

Разделять/отделять/четко ограничивать полномочия.

Небольшой сервис, управляющий ключом, например, а остальные не имеют к ключам доступа, а только к этому сервису обращаются. А он им разрешает делать только то, что можно.

Или пример как работает CloudFlare KeyLess посмотрите.

Answer 3

[sim3x]

переменные окружения

$ cat .env
varname1=123
varname2=234

#!/bin/bash

echo Vars import to env
export $(cat .env | xargs)

stackoverflow.com/a/20909045

Comments

[Сергей Соколов]

Это не вызывает сложностей. Вопрос – где и как лучше хранить ключи? Чтобы не у себя на буке и вручную их потом копировать.

[sim3x]

Сергей Соколов:
скорее бюрократический вопрос
У девов не должно быть ключей от продакшена
При етом девы могут иметь общие ключи

А ключи от продакшена - тут уже вопрос паранои и доверия девопсам

stackoverflow.com/questions/712504/best-practices-...
https://www.reddit.com/r/sysadmin/comments/2j9wo4/...

[Сергей Соколов]

sim3x: keepAss и подобные это хорошо, но из них не вытащишь автоматом содержимое. Хочется, запуская деплой, всего один раз ввести вручную «суперпароль» – и по нему деплой скрипт бы получал (откуда?) ключи-пароли и использовал/прописывал их куда нужно.

[sim3x]

Сергей Соколов:
хотелки, то понятны, только вот решения общего пока что не видел

Если б делал решение для себя, то делал на уровне консольного скрипта с https://www.gnupg.org/documentation/manpage.html

есть keys.encrypted
- распечатан и сохранен в сейф
- сохранен в репозитории с рабочим кодом

есть for_devops.key
- распечатан и сохранен в сейф
- хранится у девопса

есть пароль
- распечатан и сохранен в другой сейф
- пароль знает только несколько человек

нужно задеплоить, запускаем магический скрипт, вводим пароль и на удаленной магшине файл превращается в переменные

[sim3x]

длинна ключа 4k-1М
пароля-фразы 12+
на елиптических кривых

[Сергей Соколов]

да, это вариант «поднимаем свой cli-keepAss на коленке», в главной роли gpg. В общем-то, неплохой, кстати! Подумаю. Надеюсь, кто-то подскажет вдруг существующее industry-grade решение.

[sim3x]

Сергей Соколов: если на реддите не нашли...
Но сам буду рад скрипту или протоколу для работы с такими вещами

[Сергей Соколов]

sim3x: там пара дорогущих решений для больших компаний с кучей паролей. Подожду ещё вариантов.