Пытаемся внедрить Capistrano для развертывания релизов на серверах. Все бы хорошо, если бы не праведная паранойя администратора. В связи с этим возникает вопрос: какими средствами правильно ограничить набор разрешенных действий для пользователя, используемого для деплоя. Равно как и список ресурсов файловой системы, к которым пользователь должен иметь (или не иметь) доступ.
В голову приходит всего 2 варианта:
— пляски с ~/.ssh/authorized_keys и command
— AppArmor & SELinux
у меня hubot сидит отдельно в контейнере на далекой машине, у него есть все ключи от серверов на которые он умеет ходить, и умеет он только capistrano запускать. Т.е. на те сервера попасть руками невозможно, выполнить там что-то в шеле тоже.
Тем не менее никто в таком случае не помешает в конфиг деплоя добавить вредоносный код, например. Он прекрасно выполнится, даже при отсутствии доступа к серверу с машины девелопера, так ведь?
я же написал что hubot стоит на удалённой машине, конфиги деплоя лежат там же, как вы туда попадёте? Тем более если вы туда попали каким-то волшебным образом, то зачем мучатся с конфигами, когда вот здесь же лежат уже ключи от всех серверов
чтобы было понятно, у разработчика ничего нет, в плане ./config/debloy.rb нету. Разработчик пишет код, коммитит его в репозиторий, если у него есть доступ к hubot'у, то посылает ему в чатик `cap deploy:update` например. Hubot смотрит у себя deploy.rb и выполняет то что там написано.
В таком случае администратор должен писать (ну или, по-крайней мере, контролировать) deploy-скрипты, вместо того, чтобы контролировать допустимые действия. Больше похоже на уход от проблемы, на мой взгляд.
ну у меня не было вашей проблемы, я решал другую, зоопарк серверов на которые надо деплоить. Написал deploy скрипт и забыл, пишешь в одно место боту, а он там всё сам делает.
Средний
