Script Security Plugin

Guía del usuario

(adaptado de la información sobre Template plugin en la guía de CloudBees Plugins)

Varios complementos de Jenkins requieren que los usuarios definan scripts personalizados, más comúnmente en el lenguaje Groovy, para personalizar el comportamiento de Jenkins. Si todos los que escriben estos scripts son administradores de Jenkins—específicamente si tienen el permiso Overall/RunScripts, usado por ejemplo por el enlace de Script Console—entonces pueden escribir los scripts que quieran. Estos scripts pueden referirse directamente a objetos internos de Jenkins usando la misma API que se ofrece a los complementos. Estos usuarios deben ser completamente confiables, ya que pueden hacer cualquier cosa en Jenkins (incluso cambiar su configuración de seguridad o ejecutar comandos de shell en el servidor).

Sin embargo, si algunos autores de scripts son "usuarios normales" con solo permisos más limitados, como Job/Configure, no es apropiado permitirles ejecutar scripts arbitrarios. Para soportar tal división de roles, el complemento de la librería Script Security puede integrarse en varios complementos de funcionalidades. Este soporta dos sistemas relacionados: aprobación de scripts, y sandboxing de Groovy.

Aprobación de scripts

El primer sistema de seguridad, y el más simple, es permitir que se ejecute cualquier tipo de script, pero solo con la aprobación de un administrador. Hay una lista mantenida globalmente de scripts aprobados que se consideran que no realizan ninguna acción maliciosa.

Cuando un administrador guarda algún tipo de configuración (por ejemplo, un trabajo), esos scripts que fueron editados por el administrador se aprueban automáticamente y están listos para ejecutarse sin más intervención. Para los scripts que fueron enviados por usuarios con menos privilegios, habrá advertencias apropiadas indicando que se requiere aprobación. Los administradores pueden aprobar esos scripts usando la página de configuración de Script Approval o editando el script y guardándolo. En versiones anteriores de Script Security Plugin, los administradores podían aprobar automáticamente scripts enviados por usuarios sin privilegios al guardarlos sin hacer ningún cambio, pero esta funcionalidad se deshabilitó para prevenir ataques basados en ingeniería social. ("Guardar" usualmente significa desde la interfaz web, pero también podría significar subir una nueva configuración XML vía REST o CLI.)

Cuando un no administrador guarda una configuración de plantilla, se verifica si cualquiera de los scripts contenidos ha sido editado respecto a un texto aprobado. (Más precisamente, si el contenido solicitado ha sido aprobado alguna vez antes.) Si no ha sido aprobado, se añade una solicitud de aprobación de este script a una cola. (También se muestra una advertencia en la interfaz de la pantalla de configuración cuando el texto actual de un script no está aprobado actualmente.)

Un administrador puede ahora ir a Manage Jenkins » In-process Script Approval donde se mostrará una lista de los scripts pendientes de aprobación. Suponiendo que no se esté solicitando nada de apariencia peligrosa, simplemente haga clic en Approve para permitir que el script se ejecute de aquí en adelante.

Si intenta ejecutar un script no aprobado, simplemente fallará, típicamente con un mensaje explicando que está pendiente de aprobación. Puede reintentar una vez que el script haya sido aprobado. Los detalles de este comportamiento pueden variar según el complemento de funcionalidad que integre esta librería.

Sandboxing de Groovy

Esperar a que un administrador apruebe cada cambio en un script, sin importar lo aparentemente trivial que sea, podría ser inaceptable en un equipo distribuido entre zonas horarias o durante plazos ajustados. Como opción alternativa, el sistema de Script Security permite que los scripts de Groovy se ejecuten sin aprobación siempre que se limiten a operaciones consideradas inherentemente seguras. Este entorno de ejecución limitado se llama sandbox. (Actualmente no hay implementaciones de sandbox disponibles para otros lenguajes, por lo que todos esos scripts deben ser aprobados si son configurados por no administradores.)

Para cambiar a este modo, simplemente marque la casilla Use Groovy Sandbox debajo del campo de entrada del script Groovy. Los scripts en sandbox pueden ejecutarse inmediatamente por cualquier persona. (Incluso los administradores, aunque el script está sujeto a las mismas restricciones sin importar quién lo haya escrito.) Cuando el script se ejecuta, cada llamada a método, construcción de objeto y acceso a campo se verifica contra una lista blanca de operaciones aprobadas. Si se intenta una operación no aprobada, el script se detiene y la característica correspondiente de Jenkins no puede usarse aún.

El complemento Script Security incluye una pequeña lista blanca predeterminada, y los complementos integradores pueden añadir operaciones a esa lista (típicamente métodos específicos de ese complemento).

Pero usted no está limitado a la lista blanca predeterminada: cada vez que un script falla antes de ejecutar una operación que aún no está en la lista blanca, esa operación se añade automáticamente a otra cola de aprobación. Un administrador puede ir a la misma página descrita anteriormente para la aprobación de scripts completos, y ver una lista de aprobaciones de operaciones pendientes. Si se hace clic en Approve junto a la firma de una operación, se añade inmediatamente a la lista blanca y queda disponible para scripts en sandbox.

La mayoría de las firmas tendrán la forma method class.Name methodName arg1Type arg2Type…, indicando una llamada a un método Java con una clase "receptora" específica (this), nombre de método, y lista de tipos de argumentos (o parámetros). (La firma más general de una llamada a método intentada será ofrecida para aprobación, incluso cuando el objeto real sobre el que se iba a llamar era de un tipo más específico que sobrescribe ese método.) También puede ver staticMethod para métodos estáticos (de clase), new para constructores, y field para accesos a campos (obtener o establecer).

Los administradores en entornos sensibles a la seguridad deben considerar cuidadosamente qué operaciones incluir en la lista blanca. Las operaciones que cambian el estado de objetos persistidos (como trabajos de Jenkins) generalmente deben denegarse. La mayoría de los métodos getSomething son inofensivos.