Plugin Jenkins offrant des workflows d'approbation de scripts et un sandboxing Groovy pour garantir une exécution sécurisée des scripts, avec des contrôles de permissions tenant compte des ACL et une gestion de liste blanche pour les administrateurs.
(adapté des informations du Plugin Template dans le guide des plugins CloudBees)
Divers plugins Jenkins exigent que les utilisateurs définissent des scripts personnalisés, le plus souvent en langage Groovy, pour personnaliser le comportement de Jenkins. Si tous ceux qui écrivent ces scripts sont des administrateurs Jenkins — plus précisément s'ils disposent de la permission Overall/RunScripts, utilisée par exemple par le lien Console de scripts — alors ils peuvent écrire les scripts de leur choix. Ces scripts peuvent référencer directement des objets internes de Jenkins en utilisant la même API offerte aux plugins. Ces utilisateurs doivent être complètement fiables, car ils peuvent tout faire sur Jenkins (même modifier ses paramètres de sécurité ou exécuter des commandes shell sur le serveur).
Cependant, si certains auteurs de scripts sont des « utilisateurs normaux » avec des permissions plus limitées, telles que Job/Configure, il est inapproprié de les laisser exécuter des scripts arbitraires. Pour soutenir une telle division des rôles, le plugin de bibliothèque Script Security peut être intégré dans divers plugins fonctionnels. Il prend en charge deux systèmes connexes : l'approbation de scripts et le sandboxing Groovy.
Le premier système de sécurité, et le plus simple, consiste à autoriser l'exécution de tout type de script, mais uniquement avec l'approbation d'un administrateur. Il existe une liste globalement maintenue de scripts approuvés qui sont considérés comme n'effectuant aucune action malveillante.
Lorsqu'un administrateur enregistre une configuration (par exemple, un job), les scripts qui ont été édités par l'administrateur sont automatiquement approuvés et prêts à être exécutés sans intervention supplémentaire. Pour les scripts soumis par des utilisateurs moins privilégiés, des avertissements appropriés indiqueront qu'une approbation est requise. Les administrateurs peuvent approuver ces scripts via la page de configuration Script Approval ou en modifiant le script et en l'enregistrant. Dans les versions précédentes du Plugin Script Security, les administrateurs pouvaient approuver automatiquement les scripts soumis par des utilisateurs non privilégiés en les enregistrant sans effectuer de modifications, mais cette fonctionnalité a été désactivée pour prévenir les attaques d'ingénierie sociale. (« Enregistrer » signifie généralement via l'interface Web, mais peut aussi signifier le téléchargement d'une nouvelle configuration XML via REST ou CLI.)
Lorsqu'un non-administrateur enregistre une configuration de modèle, une vérification est effectuée pour savoir si des scripts contenus ont été édités par rapport à un texte approuvé. (Plus précisément, si le contenu demandé a déjà été approuvé auparavant.) Si ce n'est pas le cas, une demande d'approbation de ce script est ajoutée à une file d'attente. (Un avertissement est également affiché dans l'interface de l'écran de configuration lorsque le texte actuel d'un script n'est pas actuellement approuvé.)
Un administrateur peut maintenant se rendre dans Gérer Jenkins » Approbation de script en cours où une liste des scripts en attente d'approbation sera affichée. En supposant que rien de dangereux n'est demandé, il suffit de cliquer sur Approuver pour que le script puisse être exécuté par la suite.
Si vous essayez d'exécuter un script non approuvé, il échouera simplement, généralement avec un message expliquant qu'il est en attente d'approbation. Vous pouvez réessayer une fois le script approuvé. Les détails de ce comportement peuvent varier selon le plugin fonctionnel intégrant cette bibliothèque.
Attendre qu'un administrateur approuve chaque modification d'un script, même apparemment triviale, peut être inacceptable dans une équipe répartie sur plusieurs fuseaux horaires ou lors de délais serrés. En alternative, le système Script Security permet d'exécuter des scripts Groovy sans approbation tant qu'ils se limitent à des opérations considérées comme intrinsèquement sûres. Cet environnement d'exécution limité est appelé un bac à sable (sandbox). (Actuellement, aucune implémentation de bac à sable n'est disponible pour d'autres langages, donc tous ces scripts doivent être approuvés s'ils sont configurés par des non-administrateurs.)
Pour passer à ce mode, cochez simplement la case Utiliser le bac à sable Groovy sous le champ de saisie du script Groovy. Les scripts en bac à sable peuvent être exécutés immédiatement par tout le monde (même les administrateurs, bien que le script soit soumis aux mêmes restrictions, quel que soit son auteur). Lorsque le script est exécuté, chaque appel de méthode, construction d'objet et accès à un champ est vérifié par rapport à une liste blanche d'opérations approuvées. Si une opération non approuvée est tentée, le script est tué et la fonctionnalité Jenkins correspondante ne peut pas encore être utilisée.
Le plugin Script Security est livré avec une petite liste blanche par défaut, et les plugins intégrateurs peuvent ajouter des opérations à cette liste (généralement des méthodes spécifiques à ce plugin).
Mais vous n'êtes pas limité à la liste blanche par défaut : chaque fois qu'un script échoue avant d'exécuter une opération qui n'est pas encore dans la liste blanche, cette opération est automatiquement ajoutée à une autre file d'attente d'approbation. Un administrateur peut se rendre sur la même page décrite ci-dessus pour l'approbation de scripts entiers et voir une liste des approbations d'opérations en attente. Si Approuver est cliqué à côté de la signature d'une opération, celle-ci est immédiatement ajoutée à la liste blanche et disponible pour les scripts en bac à sable.
La plupart des signatures sont de la forme method class.NomMéthode typeArg1 typeArg2…, indiquant un appel de méthode Java avec une classe « réceptrice » spécifique (this), un nom de méthode et une liste de types d'arguments (ou paramètres). (La signature la plus générale d'un appel de méthode tenté sera proposée pour approbation, même si l'objet réel sur lequel il devait être appelé était d'un type plus spécifique surchargeant cette méthode.) Vous pouvez également voir staticMethod pour les méthodes statiques (de classe), new pour les constructeurs et field pour les accès aux champs (get ou set).
Les administrateurs dans des environnements sensibles à la sécurité doivent examiner attentivement les opérations à mettre sur liste blanche. Les opérations qui modifient l'état des objets persistés (tels que les jobs Jenkins) doivent généralement être refusées. La plupart des méthodes getSomething sont inoffensives.
