Script Security Plugin

Руководство пользователя

(адаптировано из информации о Template plugin в руководстве CloudBees Plugins)

Различные плагины Jenkins требуют, чтобы пользователи определяли пользовательские скрипты, чаще всего на языке Groovy, для настройки поведения Jenkins. Если все, кто пишет эти скрипты, являются администраторами Jenkins — а именно, если у них есть разрешение Overall/RunScripts, используемое например, ссылкой Script Console, — то они могут писать любые скрипты, какие захотят. Эти скрипты могут напрямую обращаться к внутренним объектам Jenkins, используя тот же API, который предоставляется плагинам. Таким пользователям нужно полностью доверять, поскольку они могут сделать с Jenkins что угодно (даже изменить его настройки безопасности или выполнять shell-команды на сервере).

Однако, если некоторые авторы скриптов являются «обычными пользователями» с лишь более ограниченными разрешениями, такими как Job/Configure, то позволять им выполнять произвольные скрипты неуместно. Для поддержки такого разделения ролей плагин-библиотека Script Security может быть интегрирован в различные функциональные плагины. Он поддерживает две связанные системы: утверждение скриптов и Groovy- песочницу.

Утверждение скриптов

Первая и более простая система безопасности позволяет запускать любые скрипты, но только с одобрения администратора. Существует глобально поддерживаемый список одобренных скриптов, которые признаны не выполняющими вредоносных действий.

Когда администратор сохраняет какую-либо конфигурацию (например, задание), те скрипты, которые были отредактированы администратором, автоматически утверждаются и готовы к запуску без дальнейшего вмешательства. Для скриптов, отправленных пользователями с более низкими привилегиями, будут соответствующие предупреждения о том, что требуется утверждение. Администраторы могут утвердить такие скрипты на странице конфигурации Script Approval или отредактировав скрипт и сохранив его. В предыдущих версиях плагина Script Security администраторы могли автоматически утверждать скрипты, отправленные непривилегированными пользователями, сохраняя их без каких-либо изменений, но эта функциональность была отключена для предотвращения атак, основанных на социальной инженерии. («Сохранение» обычно означает через веб-интерфейс, но также может означать загрузку новой XML-конфигурации через REST или CLI.)

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

Теперь администратор может перейти в Manage Jenkins » In-process Script Approval, где будет показан список скриптов, ожидающих утверждения. Если не запрашивается ничего выглядящего опасным, просто нажмите Approve, чтобы разрешить запуск скрипта в дальнейшем.

Если вы попытаетесь запустить неутверждённый скрипт, он просто завершится ошибкой, обычно с сообщением, объясняющим, что он ожидает утверждения. Вы можете повторить попытку после того, как скрипт будет утверждён. Детали такого поведения могут различаться в зависимости от функционального плагина, интегрирующего эту библиотеку.

Песочница Groovy

Ожидание, пока администратор утвердит каждое изменение скрипта, каким бы незначительным оно ни казалось, может быть неприемлемым в команде, распределённой по часовым поясам, или при жёстких сроках. Как альтернативный вариант, система Script Security позволяет запускать Groovy-скрипты без утверждения, если они ограничиваются операциями, считающимися по своей сути безопасными. Такая ограниченная среда выполнения называется песочницей. (В настоящее время реализаций песочниц для других языков нет, поэтому все такие скрипты должны утверждаться, если они настраиваются не администраторами.)

Чтобы переключиться в этот режим, просто установите флажок Use Groovy Sandbox под полем ввода Groovy-скрипта. Скрипты в песочнице могут немедленно запускаться кем угодно. (Даже администраторами, хотя скрипт подчиняется тем же ограничениям независимо от того, кто его написал.) При запуске скрипта каждый вызов метода, создание объекта и доступ к полю проверяются на соответствие белому списку одобренных операций. Если предпринята неодобренная операция, скрипт останавливается, и соответствующая функция Jenkins пока не может использоваться.

Плагин Script Security поставляется с небольшим белым списком по умолчанию, а интегрируемые плагины могут добавлять в этот список операции (обычно методы, специфичные для этого плагина).

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

Большинство сигнатур имеют вид method class.Name methodName arg1Type arg2Type…, указывающий вызов метода Java с конкретным классом-«приёмником» (this), именем метода и списком типов аргументов (или параметров). (Для утверждения будет предложена наиболее общая сигнатура предпринятого вызова метода, даже если фактический объект, для которого он вызывался, был более конкретного типа, переопределяющего этот метод.) Вы также можете увидеть staticMethod для статических методов (класса), new для конструкторов и field для доступа к полям (get или set).

Администраторам в средах с высокими требованиями к безопасности следует тщательно обдумывать, какие операции вносить в белый список. Операции, изменяющие состояние сохраняемых объектов (таких как задания Jenkins), как правило, должны быть запрещены. Большинство методов getSomething безвредны.

Методы, учитывающие ACL

Однако имейте в виду, что даже некоторые методы-«геттеры» предназначены для проверки конкретных разрешений (с помощью ACL — списка контроля доступа), в то время как скрипты часто выполняются системным псевдопользователем, которому предоставлены все разрешения. Так, например, method hudson.model.AbstractItem getParent (который получает папку или корень Jenkins, содержащие задание) сам по себе безвреден, но возможный последующий вызов method hudson.model.ItemGroup getItems (который перечисляет задания по имени внутри папки) проверяет Job/Read. Этот второй вызов было бы опасно вносить в белый список безоговорочно, поскольку это означало бы, что пользователь, имеющий Job/Create в папке, сможет прочитать по крайней мере некоторую информацию из любых заданий в этой папке, даже тех, которые должны быть скрыты согласно стратегии авторизации на основе проектов; было бы достаточно создать в папке задание, содержащее такой Groovy-скрипт (детали будут различаться в зависимости от интегрирующего плагина):

println("I sniffed ${thisjob.getParent().getItems()}!");