В качестве примера возьмем следующий случай.
У вас есть уровень RESTful API, защищенный с помощью OAuth2. С другой стороны, чтобы пользователи могли аутентифицироваться в ваших API, вам необходимо запросить токен доступа (например, grant_type=password).
Чтобы запросить токен доступа к паролю, клиентскому приложению требуется клиент OAuth (пара ключ + секрет).
Теперь вы настроили все для использования непрерывной интеграции и непрерывного развертывания.
Во время разработки сборки скрипт сборки создает тестовые данные, включая клиентов OAuth. Очевидно, что если сборка создает тестовые данные, она предварительно удаляет все данные, созданные во время автоматических тестов.
Таким образом, вы хотите, чтобы ваше клиентское приложение использовало один из клиентов OAuth, и вы хотите избежать жесткого кодирования одного из них, поскольку они создаются с использованием инфраструктуры API, поэтому они воссоздаются с нуля. на каждой сборке.
Думайте, что интерфейс и серверная часть создаются разными сценариями сборки.
Заключение и вопрос
Как лучше организовать обмен секретами между серверной и клиентской инфраструктурой, чтобы обе они запускались и работали синхронно с одними и теми же секретами безопасности?
Некоторые идеи
Переменные среды операционной системы. Я мог бы хранить эти секреты в переменных среды машины сборки. То есть клиентская инфраструктура всегда будет создаваться и развертываться с использованием самых современных секретов.
То же, что и № 1, но эти секреты хранятся в общем каталоге на машине сборки.
