Мы находимся в процессе настройки хоста для непрерывного развертывания. Каждое приложение работает под собственной учетной записью пользователя.
В настоящее время мы рассматриваем подход, который просто позволяет машине непрерывной сборки иметь открытый ключ к учетной записи этого приложения для целей развертывания.
Есть опасения, что это может создать уязвимость, поэтому мы пытаемся увидеть, есть ли способы снизить риск. Ограничение доступа к блоку IPv4 на самом деле не вариант из-за кластерного характера нашей сторонней службы сборки, поэтому нам необходимо рассмотреть другие подходы к снижению рисков в рамках нашего процесса развертывания. Я не хочу, чтобы преимущества непрерывного развертывания нанесли вред нашей производственной среде.
Может ли кто-нибудь предложить подходы, которые могут предоставить машинам CI возможность выполнять свою работу, при этом гарантируя, что мы не создадим брешь в безопасности. В идеале подходы, которые использовались в уважаемой вами среде, чтобы избежать чисто теоретических подходов.
Хост развертывания использует виртуальную машину на основе Ubuntu 16.04.2 LTS с доступом через ssh. На сервере будет размещаться веб-приложение на основе HTTP.
Можно принудительно запустить команду при подключении, что может ограничить то, что можно сделать с помощью ключа. Существует ряд других опций, которые можно применить, включая ограничение IP-адреса источника для соединения. См. Вашу страницу руководства для authorized_keys и / или sshd для подробностей.
Для такого использования вы можете заставить команду вытащить развертывание в среду. Развертывание может быть указано в запросе на подключение, или вы можете получить последний файл.
Вы можете предоставить развертывание через NFS или использовать scp для отправки или получения сборки.
Использование ключа SSH в обычном порядке - не обязательно плохой путь. Если вы действительно обеспокоены, вы можете отделить учетную запись развертывания от учетных данных, используемых для фактического запуска службы.
Вы каждый раз создаете новый сервер или повторно используете существующий? Второй вариант с меньшей вероятностью накапливает изменения конфигурации, которые оставляют вас открытыми, но без дополнительной информации о вашем конвейере на этот вопрос сложно ответить.