Plugin Jenkins che fornisce flussi di lavoro di approvazione degli script e sandboxing Groovy per garantire l'esecuzione sicura degli script, con controlli di autorizzazione consapevoli degli ACL e gestione delle whitelist per amministratori.
(adattato dalle informazioni sul Plugin Template nella guida CloudBees Plugins)
Vari plugin di Jenkins richiedono che gli utenti definiscano script personalizzati, più comunemente in linguaggio Groovy, per personalizzare il comportamento di Jenkins. Se tutti coloro che scrivono questi script sono amministratori di Jenkins—in particolare se hanno il permesso Overall/RunScripts, utilizzato ad esempio dal collegamento Script Console—possono scrivere qualsiasi script desiderino. Questi script possono fare riferimento diretto agli oggetti interni di Jenkins utilizzando la stessa API offerta ai plugin. Tali utenti devono essere completamente fidati, poiché possono fare qualsiasi cosa su Jenkins (anche modificare le impostazioni di sicurezza o eseguire comandi shell sul server).
Tuttavia, se alcuni autori di script sono "utenti normali" con solo permessi più limitati, come Job/Configure, non è appropriato permettere loro di eseguire script arbitrari. Per supportare tale divisione dei ruoli, il plugin libreria Script Security può essere integrato in vari plugin di funzionalità. Supporta due sistemi correlati: approvazione degli script e sandboxing Groovy.
Il primo sistema di sicurezza, e più semplice, è quello di permettere l'esecuzione di qualsiasi tipo di script, ma solo con l'approvazione di un amministratore. Esiste un elenco mantenuto globalmente di script approvati che si ritiene non eseguano azioni malevole.
Quando un amministratore salva un qualche tipo di configurazione (ad esempio, un job), gli script modificati dall'amministratore vengono automaticamente approvati e sono pronti per l'esecuzione senza ulteriori interventi. Per gli script inviati da utenti con privilegi inferiori verranno visualizzati avvisi appropriati che indicano la necessità di approvazione. Gli amministratori possono approvare tali script utilizzando la pagina di configurazione di Approvazione Script o modificando lo script e salvandolo. Nelle versioni precedenti del Plugin di Sicurezza degli Script, gli amministratori potevano approvare automaticamente gli script inviati da utenti non privilegiati salvandoli senza apportare modifiche, ma questa funzionalità è stata disabilitata per prevenire attacchi di ingegneria sociale. ("Salvare" di solito significa dall'interfaccia web, ma potrebbe anche significare caricare una nuova configurazione XML tramite REST o CLI.)
Quando un non amministratore salva una configurazione modello, viene effettuato un controllo per verificare se eventuali script contenuti sono stati modificati rispetto a un testo approvato. (Più precisamente, se il contenuto richiesto è mai stato approvato in precedenza.) Se non è stato approvato, una richiesta di approvazione per questo script viene aggiunta a una coda. (Un avviso viene anche visualizzato nell' interfaccia di configurazione quando il testo corrente di uno script non è attualmente approvato.)
Un amministratore può ora andare in Gestisci Jenkins » Approvazione script in-process dove verrà mostrato un elenco di script in attesa di approvazione. Supponendo che non venga richiesto nulla di pericoloso, basta fare clic su Approva per permettere l'esecuzione dello script d'ora in poi.
Se si tenta di eseguire uno script non approvato, fallirà semplicemente, tipicamente con un messaggio che spiega che è in attesa di approvazione. È possibile riprovare una volta che lo script è stato approvato. I dettagli di questo comportamento possono variare a seconda del plugin di funzionalità che integra questa libreria.
Aspettare che un amministratore approvi ogni modifica a uno script, per quanto apparentemente banale, potrebbe essere inaccettabile in un team distribuito su fusi orari diversi o durante scadenze strette. Come opzione alternativa, il sistema Script Security permette l'esecuzione di script Groovy senza approvazione purché si limitino a operazioni considerate intrinsecamente sicure. Questo ambiente di esecuzione limitato è chiamato sandbox. (Attualmente non sono disponibili implementazioni sandbox per altri linguaggi, quindi tutti questi script devono essere approvati se configurati da non amministratori.)
Per passare a questa modalità, basta spuntare la casella Usa Groovy Sandbox sotto il campo di inserimento dello script Groovy. Gli script in sandbox possono essere eseguiti immediatamente da chiunque. (Anche gli amministratori, anche se lo script è soggetto alle stesse restrizioni indipendentemente da chi lo ha scritto.) Quando lo script viene eseguito, ogni chiamata a metodo, costruzione di oggetto e accesso a campo viene controllata rispetto a una whitelist di operazioni approvate. Se viene tentata un'operazione non approvata, lo script viene terminato e la corrispondente funzionalità di Jenkins non può ancora essere utilizzata.
Il plugin Script Security viene fornito con una piccola whitelist predefinita, e i plugin che lo integrano possono aggiungere operazioni a tale elenco (tipicamente metodi specifici di quel plugin).
Ma non sei limitato alla whitelist predefinita: ogni volta che uno script fallisce prima di eseguire un'operazione non ancora inserita nella whitelist, tale operazione viene automaticamente aggiunta a un'altra coda di approvazione. Un amministratore può andare nella stessa pagina descritta sopra per l'approvazione di interi script e vedere un elenco di approvazioni di operazioni in sospeso. Se si fa clic su Approva accanto alla firma di un'operazione, viene immediatamente aggiunta alla whitelist e resa disponibile per gli script in sandbox.
La maggior parte delle firme sono della forma method class.Name methodName arg1Type arg2Type…,
indicando una chiamata a metodo Java con una specifica classe "ricevente" (this), nome del metodo e
lista di tipi di argomenti (o parametri). (Verrà offerta per l'approvazione la firma più generale
di una chiamata a metodo tentata, anche quando l'oggetto reale su cui doveva essere chiamato era
di un tipo più specifico che sovrascrive quel metodo.) Potresti anche vedere staticMethod per
metodi statici (di classe), new per costruttori e field per accessi a campi (get o set).
Gli amministratori in ambienti sensibili alla sicurezza dovrebbero considerare attentamente quali
operazioni inserire nella whitelist. Le operazioni che cambiano lo stato di oggetti persistenti (come
i job Jenkins) dovrebbero generalmente essere negate. La maggior parte dei metodi getSomething sono innocui.
