Jenkins
Sommaire
Présentation
Cette page a pour objet de décrire différents gestes liés à l'utilisation de l'outil Jenkins.
Bonnes pratiques
Un ensemble de bonnes pratiques sont recommandées sur le site officiel de Jenkins.
Il convient donc de les suivre dès que cela est possible.
Redéfinition des paramètres de connexion
Une fois les méthodes et comptes d'accès définis, une bonne pratique est restreindre l'accès à l'interface d'administration du Jenkins.
Du fait de cette restriction, il peut arriver, en cas d'incident ou de mauvaise configuration, que l'interface d'administration ne soit plus accessible. Par exemple :
- Le mot de passe du compte admin a été oublié
- La liaison réseau à l'annuaire des comptes (exemple : Active Directory) ne fonctionne plus
- Le(s) compte(s) d'administration a/ont été désactivé(s) par erreur
Dans ce cas, pour accéder à nouveau à l'interface d'administration et redéfinir les paramètres de connexion, il faut éditer le fichier config.xml
présent à la racine du dossier applicatif de Jenkins (généralement dans /var/lib/jenkins
) et modifier le contenu de la balise <useSecurity>
de true
à false
:
<useSecurity>true</useSecurity> ==> <useSecurity>false</useSecurity>
Il faut ensuite redémarrer Jenkins pour prise en compte de cette modification. De cette façon, l'interface d'administration du Jenkins est accessible sans aucun contrainte de sécurité.
ATTENTION ! l'interface de Jenkins étant accessible à tous pendant cette manipulation, il est recommandé de mettre en place des solutions de protection appropriées au préalable ! Par exemple, couper les interfaces réseau et accéder en mode console au serveur, restreindre l'accès à la machine par adresse IP, etc ...
Intégration avec Active Directory
Authentification
Pour activer l'authentification par Active Directory, il faut au préalable installer le plugin Active Directory.
Installation du plugin AD
Pour installer le plugin, se rendre dans la section Accueil / Administrer Jenkins / Gestion des plugins
, onglet Disponibles
(soit le chemin /pluginManager/available
dans l'URL Jenkins) et rechercher "Active Directory" dans le champ Filtre
:
Cocher la cache correspondant au plugin et cliquer sur Installer sans redémarrer
pour installer le plugin.
Activation de l'authenfication AD
Une fois le plugin installé, se rendre dans la section Accueil / Administrer Jenkins / Configurer la sécurité globale
(soit le chemin /configureSecurity/
dans l'URL Jenkins) et cocher la case Activer la sécurité
si ce n'est pas déjà fait.
Sélectionner ensuite Active Directory
dans la section Royaume pour la sécurité (Realm)
et cliquer sur Add Domain
. Cela a pour effet de faire apparaître un formulaire à remplir. Il est possible d'ajouter plusieurs domaines :
Renseigner alors les champs suivants :
- Nom du domaine :
- Renseigner ici le domaine concerné (exemple : jordan-lenuff.com)
- Domain controller :
- Renseigner ici l'adresse du contrôleur de domaine (exemple : ad.jordan-lenuff.com:3268)
- Site :
- Laisser vide
- Bind DN :
- Renseigner ici le DN complet du compte AD autorisé à interroger l'AD
- Bind Password :
- Le mot de passe dudit compte AD
- TLS Configuration :
- (Insecure) Trust all Certificates
Cliquer sur Test Domain
pour vérifier les informations renseignées et la bonne connexion à l'Active Directory.
ATTENTION ! Si la configuration à l'Active Directory est mal réalisée et qu'aucun compte ne peut se connecter, il pourrait être impossible de re-configurer Jenkins. Dans ce cas, dans un premier temps, afin d'éviter cette situation, dans la section Autorisations
, cocher le choix Tout le monde a accès à toutes les fonctionnalités
. Cela permettra de continuer à réaliser les actions d'administration, même en cas d'impossibilité de s'authentifier.
Valider la configuration en cliquant sur Enregistrer
.
Faire un test de connexion en cliquant sur S'identifier
en haut à droit de Jenkins :
Si la connexion échoue, retourner dans les paramètres et vérifier la configuration de connexion à l'AD.
En cas de connexion réussie, retourner dans la section Accueil / Administrer Jenkins / Configurer la sécurité globale
(soit le chemin /configureSecurity/
dans l'URL Jenkins) et cocher la case Les utilisateurs connectés peuvent tout faire
. Ainsi, seules les personnes connectées au travers l'Active Directory pourront réaliser des actions dans Jenkins.
Valider la configuration en cliquant sur Enregistrer
.
Pour ajuster le niveau d'accès des utilisateurs, suivre le chapitre suivant.
Gestion des accès
Pour gérer la gestion des accès selon les groupes d'appartenance de l'Active Directory, il faut au préalable installer le plugin Role Strategy.
Installation du plugin Role Strategy
Pour installer le plugin, se rendre dans la section Accueil / Administrer Jenkins / Gestion des plugins
, onglet Disponibles
(soit le chemin /pluginManager/available
dans l'URL Jenkins) et rechercher "Authorization Strategy" dans le champ Filtre
:
Cocher la cache correspondant au plugin et cliquer sur Installer sans redémarrer
pour installer le plugin.
Paramétrage des rôles
Menu
Une fois le plugin installé, se rendre dans la section Accueil / Administrer Jenkins / Configurer la sécurité globale
(soit le chemin /configureSecurity/
dans l'URL Jenkins), cocher la case Stratégie basée sur les rôles
dans la section Autorisations
et cliquer sur "Enregistrer" pour valider.
Cela aura pour effet de rendre disponibles les options du plugin Role Strategy précédemment installé. Pour y accéder, se rendre dans la section Accueil / Administrer Jenkins / Gérer et assigner les rôles
(soit le chemin /role-strategy/
dans l'URL Jenkins) :
La nouvelle section "Gérer et assigner les rôles" est composée des menus suivants :
- Gérer les rôles
- Permet de définir des rôles globaux ou par projet
- Assigner les rôles
- Permet d'assigner un rôle à un groupe et/ou utilisateur
- Role Strategy Macros
- Permet d'affiner la gestion des accès avec le plugin supplémentaire RoleMacroExtension
Créer des rôles
- Rôles globaux
Les rôles globaux sont applicables sur tous les objets Jenkins sans distinction. Pour créer un rôle global, lui donner un nom dans le champ "Rôle à ajouter" de la section "Rôles globaux" et cliquer sur Ajouter
. Le rôle nouvellement créé s'affiche ensuite dans le tableau de la section "Rôles globaux". Affecter ensuite les différents droits désirés dans la matrice.
- Rôles de projets
Les rôles de projets permettent de définir des droits de façon plus précise sur les projets Jenkins. Pour créer un rôle de projet, lui donner un nom dans le champ "Rôle à ajouter" de la section "Rôles de projets", lui affecter un "Patron" à respecter puis cliquer sur Ajouter
. Le patron est expression régulière qui doit respecter un schéma de chaîne de caractère correspondant au(x) nom(s) de projet(s) désiré(s). Le rôle nouvellement créé s'affiche ensuite dans le tableau de la section "Rôles de projets". Affecter ensuite les différents droits désirés dans la matrice.
NB : Il est possible de s'aider de l'outil en ligne https://regex101.com/ pour générer des regex (regular expressions). Par exemple, la regex "web*" correspondra à tous les projets commençant par la chaîne de caractères "web".
- Slave roles
Il s'agit ici des rôles qui serviront à gérer les instances esclaves de Jenkins. La méthode de création de rôle est la même que pour les "Rôles de projets".
Assigner des rôles
Une fois les rôles définis dans le menu "Gérer les rôles", il est alors possible de les "mapper" (les faire correspondre) avec les groupes et/utilisateurs de l'Active Directory.
La méthode pour faire correspondre un utilisateur/groupe à un rôle est la même pour tout les types de rôles (Rôles globaux, Item roles (Rôles de projets), Node roles (Slave roles)). Il faut saisir l'identifiant du compte de l'utilisateur ou le nom du groupe (la saisie est insensible à la casse) et cliquer sur Ajouter
. Cela aura pour effet d'ajouter l'utilisateur ou groupe dans le tableau de la section concernée.
Ensuite, il faut simplement cocher la case correspond au(x) rôle(s) à affecter à l'utilisateur ou groupe précédemment ajouté.
Exemple
Par exemple, sur un Jenkins où il y a 5 groupes de jobs à la racine :
- ServiceA
- Contenant l'ensemble des projets du service A
- ServiceB
- Contenant l'ensemble des projets du service B
- ServiceC
- Contenant l'ensemble des projets du service C
- Presta
- Contenant l'ensemble des projets sur lesquels travaillent des sociétés externes (sous-traitants)
Dans les dossiers ServiceA
, ServiceB
et ServiceC
se trouvent les projets respectifs des services en question.
Dans le dossier Presta
se trouvent un dossier par société externe. Dans chaque dossier de société externe se trouvent les différents projets sur lesquels elle travaille.
Ainsi, les utilisateurs de Jenkins doivent accéder aux différentes ressources de la façon suivante :
- Tous les utilisateurs, exceptées les sociétés externes, voient les dossiers se trouvant à la racine de Jenkins (
ServiceA
,ServiceB
,ServiceC
etPresta
). - Pour les utilisateurs travaillant sur
ServiceA
,ServiceB
ouServiceC
, ils peuvent uniquement parcourir leur dossier respectif et voir leurs sous-dossiers. - Pour les utilisateurs des sociétés externes, ils peuvent se rendre dans le dossier
Presta
mais ils ne peuvent voir et parcourir que les sous-dossiers correspondants aux projets sur lesquels ils travaillent.- Ils ne doivent donc pas voir les dossiers des autres sociétés externes
- Les administrateurs de Jenkins ont accès à toutes les ressources.
Pour mettre en oeuvre ces droits d'accès, il définir deux rôles globaux :
- Le rôle "admin" : qui donne tous les droits aux administrateurs
- Le rôle "user" : qui donne aux utilisateurs authentifiés les accès aux différents menus de base de Jenkins
Il faut ensuite définir les rôles de projets en fonction des besoins ci-dessus :
- Pour chaque dossier
ServiceA
,ServiceB
etServiceC
, il faut créer le rôle avec son parton associé de la forme '""ServiceA" -> "^ServiceA.*" par exemple.- De cette manière, les utilisateurs auront accès à toute l'arborescence de leur dossier.
- Les droits à affecter dépendent du besoin.
- Pour le dossier
Presta
, il faut créer le rôle '""Presta" avec le parton "Presta".- Le droit à affecter est uniquement '"Job/Read".
- Ainsi, les sociétés externes pourront voir le dossier
Presta
et se rendre à l'intérieur, rien de plus.
- Pour les sous-dossiers de
Presta
, il faudra créer autant de rôles de projets que de sociétés de la forme "SociétéExterne" -> "^Presta/SociétéExterne.*" par exemple.- De cette manière, les utilisateurs verront apparaître le dossier SociétéExterne dans le dossier Presta et pourront le parcourir.
- Les droits à affecter dépendent du besoin.
Enfin, les rôles étant créés, il faudra les assigner de la façon suivante :
- Rôles globaux :
- Groupe d'administrateurs Jenkins ==> admin
- Tous les groupes d'utilisateurs Jenkins ==> user
- Item roles :
- Groupes d'utilisateurs internes (
ServiceA
,ServiceB
etServiceC
) ==> ServiceA, ServiceB ou ServiceC - Groupe d'utilisateurs externes ==> Presta (obligatoire) et <rôle de projet de la société> (exemple SociétéExterne)
- Groupes d'utilisateurs internes (
Choix version de PHP
Avec la variable d'environnement $PATH
Dans le cadre d'une utilisation multiple des versions de PHP, il est nécessaire de pouvoir indiquer aux jobs Jenkins quelle version de PHP utiliser pour le build.
A ce titre, le plugin Environment Injector a été installé.
Pour indiquer à un projet Jenkins quel version de PHP utiliser, se rendre sur le projet en question et cliquer sur Configurer :
Dans la configuration du projet, se rendre dans la section Environnements de Build et cliquer sur Inject environment variables to the build process :
Dans la section précédemment ouverte, dans le champ Properties Content, définir le PATH
comme ceci : /local/php/php7/bin:$PATH
. Dans cet exemple, le chemin des binaires PHP 7 a été mis devant la variable $PATH
. De ce fait, en cas de présence déjà existante de chemins d'autres versions de PHP, ce sera celui de PHP 7 qui prévaudra.
Pour tester et vérifier la bonne prise en compte, dans la section Build, ajouter une étape Exécuter un script shell et renseigner les lignes suivantes :
which php composer -v
Cliquer sur Sauver :
Lancer ensuite un build en cliquant sur Lancer un build :
Un build supplémentaire apparaît dans la section Historique des builds :
Cliquer sur le dernier build puis cliquer sur Console Output pour afficher le détail :
Cela affiche la sortie de la console avec le résultat des commandes définies plus haut dans la section Exécuter un script shell
La version de PHP utilisé est bien la 7, comme défini plus haut, et Composer est fonctionnel.
Avec Gradle via du Groovy
Lors de son installation, Jenkins est livré avec 3 outils globaux configurables : Maven, Gradle et JDK.
Ces outils offrent des possibilités intéressantes, qui sont difficiles à mettre en oeuvre pour du PHP. De ce fait, pour charger les binaires de PHP selon la version souhaitée, il est possible de galvauder Gradle.
Côté administration Jenkins
Aller dans l'administration Jenkins puis dans Configuration globale des outils.
Dans la section Gradle, cliquer sur Ajouter Gradle pour ajouter une version de PHP :
Nommer le champ name PHP suivi de la version majeure concernée, définir GRADLE_HOME sur la localisation du répertoire d'installation de la version de PHP et décocher Install automatically :
Répéter l'action autant de fois que de versions différentes de PHP désirées et cliquer sur Enregistrer.
Cette action aura pour effet de rajouter dans le PATH le dossier bin d'une version de PHP lorsqu'elle sera appelée via un script Groovy.
Côté utilisation Jenkins
Lors de la création/modification d'un job Jenkins au travers d'un script Groovy, pour définir la version de PHP à utiliser, il suffit d'appeler l'outil gradle correspondant à la version de PHP à utiliser. Cela se fait dans la section tools, après la déclaration de l'agent, au début du script. Exemple pour utiliser PHP en version 7 :
pipeline {
agent any
tools {
gradle 'PHP7'
}
stages {
stage('Test appel PHP') {
steps {
sh '''
php -v
which php
echo $PATH
composer --version
'''
}
}
}
}
Cela aura pour effet de produire la sortie suivante :
... [workspace] Running shell script + php -v PHP 7.2.19 (cli) (built: Jul 25 2019 16:09:54) ( ZTS ) Copyright (c) 1997-2018 The PHP Group Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies with Xdebug v2.7.2, Copyright (c) 2002-2019, by Derick Rethans + which php /local/php/php7/bin/php + echo /local/php/php7/bin:/local/php/php7/bin:/var/lib/jenkins/tools/hudson.tasks.Maven_MavenInstallation/MAVEN_3.5.0/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:/local/mysql/5.6.23/bin:/local/mysql/5.6.23/share/mysql:/home/tools/bin:/usr/lib/oracle/10.2.0.4/client64/bin:/local/www/2.4.12/bin/:. /local/php/php7/bin:/local/php/php7/bin:/var/lib/jenkins/tools/hudson.tasks.Maven_MavenInstallation/MAVEN_3.5.0/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:/local/mysql/5.6.23/bin:/local/mysql/5.6.23/share/mysql:/home/tools/bin:/usr/lib/oracle/10.2.0.4/client64/bin:/local/www/2.4.12/bin/:. + composer --version Composer version 1.5.2 2017-09-11 16:59:25 ...
Plugins
Environment Injector
Le plugin EnvInject fournit les fonctionnalités suivantes:
- Supprime des variables d'environnement héritées par le processus Java Jenkins
- Injecte des variables d'environnement au démarrage du noeud (maître / esclave)
- Exécute un script de configuration avant ou/et après une extraction SCM pour une exécution
- Injecte des variables d'environnement avant ou/et après une extraction SCM pour une exécution
- Injecte des variables d'environnement en tant qu'étape de construction pour une exécution
- Injecte des valeurs de mot de passe pour une exécution
- Exporte des variables d'environnement à la fin de la construction afin de connaître l'ensemble des variables d'environnement utilisées pour chaque construction
Plus d'informations sur https://plugins.jenkins.io/envinject.
Récupérer les mots de passe stockés
Procédure trouvée sur https://looselytyped.com/blog/2017/10/25/uncovering-passwords-in-jenkins/.
Point de départ
La première chose qui est nécessaire est d'avoir accès au serveur Jenkins lui-même.
Commencer par se connecter en SSH sur le serveur Jenkins et localiser le home directory ($JENKINS_HOME
) de Jenkins avec la commande suivante :
grep jenkins /etc/passwd|awk -F: '{print $6}'
Ensuite, il faut déterminer où est stocké le mot de passe dans Jenkins. Jenkins utilise plusieurs emplacements différents pour stocker les informations d'identification, selon qu'elles sont au niveau du système ou spécifiques à un job. Quelques fichiers et répertoires qui stockent les informations d’identification sont :
$JENKINS_HOME/credentials.xml
- Ce fichier est utilisé par le plugin Credentials utilise pour stocker les informations d'identification.
$JENKINS_HOME/jobs/
- C'est le répertoire dans lequel Jenkins stocke tous les jobs qui ont été configurés, ainsi que leurs fichiers config.xml respectifs. Dans ces fichiers se trouveront toutes les informations d'identification qui ont été fournies dans le cadre de la configuration du job.
- Par exemple, le plug-in Artifactory permet de remplacer les informations d'identification par défaut pour chaque job. De tels remplacements sont stockés dans la configuration des jobs et ils sont localisés (chiffrés bien entendu) ici.
Généralement, un grep dans $JENKINS_HOME
avec le nom d'utilisateur dont on souhaite découvrir les informations d'identification est le moyen le plus rapide de déterminer où chercher.
Détermination de la classe utilisée pour le cryptage / décryptage
Une fois le fichier dans lequel rechercher à été trouvé, l'étape suivante consiste à déterminer comment déchiffrer le mot de passe. Heureusement, Jenkins stocke la quasi-totalité de sa configuration dans des fichiers XML. La visualisation du fichier peut donc se faire via un cat
ou un less
, ou simplement via un scp
du fichier sur la machine locale et le lire avec un éditeur de texte.
Par exemple, si le nom d'utilisateur est jenkins-user@mycompany.com et que les informations d'identification recherchées sont effectivement stockées dans credentials.xml
, le fichier peut contenir un extrait comme celui-ci :
<username>jenkins-user@mycompany.com</username>
<password>{AQAAABAAAAAgyqp9mI73xTYaYkaMRNolxwxR+X0qev7q6Hb3KcchbM9VA5ERj0RG1Nrl/aFw7haU}</password>
- L'extrait de code peut être différent de celui de l'exemple, mais tant que le nom d'utilisateur correspond, cela signifie qu'on est au bon endroit.
La balise <password/>
apparaît. Il reste donc à décrypter son contenu.
Remonter ensuite dans la hiérarchie des balises jusqu'à la rencontre d'une balise ressemblant à un nom de classe Java pleinement qualifié. Par exemple :
<com.cloudbees.plugins.credentials.impl.UsernamePasswordCredentialsImpl>
<scope>SYSTEM</scope>
<id>5dc3bbe5-e5a6-496e-a616-199a207d8122</id>
<description>This is a user</description>
<username>jenkins-user@mycompany.com</username>
<password>{AQAAABAAAAAQ5Qp/KX1Ibliy/23sM6e3Lepwa/OObLtGHC5svihnTr4=}</password>
</com.cloudbees.plugins.credentials.impl.UsernamePasswordCredentialsImpl>
Cela permet de connaître la classe que Jenkins instancie pour prendre en charge cette propriété.
Il faut donc maintenant trouver le code source et déterminer le mécanisme utilisé par cette classe pour chiffrer / déchiffrer le mot de passe. Utiliser un moteur de recherche pour trouver le code source. Dans ce cas précis, il suffit de chercher com.cloudbees.plugins.credentials.impl.UsernamePasswordCredentialsImpl
.
Un rapide examen du code source fait ressortir ce constructeur :
@DataBoundConstructor
@SuppressWarnings("unused") // by stapler
public UsernamePasswordCredentialsImpl(@CheckForNull CredentialsScope scope,
@CheckForNull String id, @CheckForNull String description,
@CheckForNull String username, @CheckForNull String password) {
super(scope, id, description);
this.username = Util.fixNull(username);
this.password = Secret.fromString(password);
}
Ainsi, com.cloudbees.plugins.credentials.impl.UsernamePasswordCredentialsImpl
utilise hudson.util.Secret
pour chiffrer le mot de passe. Lors de la recherche suivante, le code source hudson.util.Secrets
indique à son tour une méthode de déchiffrement :
@CheckForNull
public static Secret decrypt(@CheckForNull String data) {
...
}
La classe est utilisée pour chiffrer / déchiffrer le mot de passe est donc Secret
. Il faut ensuite découvrir comment l'utiliser. Il pourrait être possible d'essayer de simplifier l’implémentation et d’arriver en quelque sorte à l’exécuter de façon isolée, peut-être dans une classe de test avec une méthode principale, mais cela serait compliqué, surtout si cette classe a des dépendances sur d’autres classes.
Il est donc nécessaire d'avoir un environnement d'exécution où il sera possible charger cette classe, ainsi que toutes ses dépendances, et de simplement appeler hudson.util.Secret#déchiffrer
en passant le mot de passe trouvé dans credentials.xml
. Jenkins fourni cet environnement d'exécution.
Utiliser la console de script pour découvrir le mot de passe
Jenkins est livré avec une console de script qu'il est possible utiliser pour exécuter arbitrairement des scripts Groovy. Dans cette console, exécuter le code suivant permettra de révéler un mot de passe :
import hudson.util.Secret;
println Secret.decrypt("{AQAAABAAAAAQ5Qp/KX1Ibliy/23sM6e3Lepwa/OObLtGHC5svihnTr4=}");
// Résultat : jenkins
Le mot de passe est ainsi retrouvé.