Разве плохо использовать sudo от Jenkins?

Я использую плагин Publish Over SSH для развертывания моих приложений Jenkinsв разных средах. Некоторые задания по развертыванию выполняют подготовку среды и такие вещи, как остановка и перезапуск системной службы сервера приложений. Некоторые из этих команд требуют sudo.

Мне просто любопытно, может ли быть плохой практикой безопасности требовать sudo для удаленной публикации и выполнения заданий Jenkins. Должны ли мы изменить политику безопасности на целевом хосте, чтобы разрешить выполнение необходимых функций без sudo?

Нет, на самом деле это хорошая практика безопасности, когда вам нужны привилегии более высокого уровня. Это причина того, что большинство дистрибутивов запрещают вход по умолчанию и фактически заставляют вас sudo suвместо того, чтобы просто печатать su- они хотят поощрять вас использовать sudo в целях безопасности. Есть несколько причин, почему:

• Аудиторская проверка. Когда вы выполняете sudo, система ведет учет того, кто sudoed и команды, которую они выполнили. Это значительно улучшает судебную экспертизу, когда вам нужно вернуться назад и выяснить, что произошло - назначить вину, уловить гнусные действия или просто устранить неисправности (что, черт возьми, произошло вчера вечером в 7 часов вечера, прежде чем этот сервер перешел в AWOL?)

• Правила судо. То, что пользователю нужно запускать что-то с повышенными привилегиями, не означает, что ему нужно запускать все с повышенными привилегиями. Использование su или добавление пользователя в wheel позволяет пользователю делать все . Однако с помощью sudo можно указать, что пользователи могут и не могут делать, используя псевдонимы команд, которые допускают использование подстановочных знаков, тем самым обеспечивая гибкие правила, которые предоставляют пользователям привилегии использовать некоторые команды, но не другие.

• Закалка. Есть возможность отключить root. Как и во всех целях и целях, он не существует и является полезным / применимым только в однопользовательском режиме - требующем перезагрузки сервера (и единственная причина, по которой это разрешено, - восстановление пароля). sudo suбольше не работает. Это делается путем установки оболочки root в / bin / nologin. что является отличным способом предотвращения многих уязвимостей эскалации root. Это, конечно, предполагает, что вы правильно используете вышеприведенный пункт (и вы по-прежнему можете предоставить конкретному пользователю с правами администратора все разрешения, хотя это подорвет вашу позицию безопасности).

Эти вещи, конечно, только часть вашей модели безопасности. Например, если у вас нет пользователей с полными административными привилегиями (а иногда даже тогда), ваш пользователь может (возможно, может) удалить журналы и историю - если вы не используете сервер журналов и системный журнал для отправки журналов из коробки. Тогда нет никакого способа положить эту кошку обратно в сумку. Конечно, если вы используете структуру каталогов с централизованной аутентификацией, то это возвращается в игру: если я скомпрометирую одну учетную запись, она скомпрометируется на всех серверах в организации - включая, вероятно, ваш сервер журналов.

Короче говоря, безопасность сложна, но sudo - отличный инструмент для создания безопасной среды, и все больше людей должны использовать ее в полной мере.

Независимо от того, разрешаете ли вы удаленный sudoили удаленный доступ к чему-либо, у SUID rootвас довольно похожая поверхность атаки. Я хотел бы остаться sudoв цепочке, потому что это позволяет вам легко ограничивать команды и имеет журналирование, которое будет иметь жизненно важное значение, если вам понадобится проверять вещи позже. sudoтакже имеет гораздо более длинную историю производства. Делать что-то еще будет меньше истории и больше изменений неприятных сюрпризов.

Есть и другие вещи, которые вы можете сделать, чтобы сделать это более безопасным, хотя:

• подтянуть ssh
• разрешить команды перезапуска только для определенных пользователей, в том числе для jenkins
• разрешить вход в систему только тем конкретным пользователям со всех внутренних IP-адресов или просто jenkins и IP-адресов переходов
• хранить журналы на удаленных ящиках, чтобы их нельзя было