|
|
| (3 révisions intermédiaires par le même utilisateur non affichées) |
| Ligne 3 : |
Ligne 3 : |
| | | | |
| | ==Bonnes pratiques== | | ==Bonnes pratiques== |
| − | Un ensemble de bonnes pratiques sont recommandées sur le [https://wiki.jenkins.io/display/JENKINS/Jenkins+Best+Practices site officiel de Jenkins]. | + | Un ensemble de bonnes pratiques est recommandé sur le [https://wiki.jenkins.io/display/JENKINS/Jenkins+Best+Practices site officiel de Jenkins]. |
| | | | |
| | Il convient donc de les suivre dès que cela est possible. | | Il convient donc de les suivre dès que cela est possible. |
| | | | |
| − | == Redéfinition des paramètres de connexion == | + | == Liste des pages == |
| − | 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.
| + | {{#subpages:default=''}} |
| − | | |
| − | 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 <code>config.xml</code> présent à la racine du dossier applicatif de Jenkins (généralement dans <code>/var/lib/jenkins</code>) et modifier le contenu de la balise <code><useSecurity></code> de <code>true</code> à <code>false</code> :
| |
| − | <syntaxhighlight lang="xml">
| |
| − | <useSecurity>true</useSecurity> ==> <useSecurity>false</useSecurity>
| |
| − | </syntaxhighlight>
| |
| − | | |
| − | 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 [https://wiki.jenkins-ci.org/display/JENKINS/Active+Directory+Plugin Active Directory].
| |
| − | ==== Installation du plugin AD ====
| |
| − | Pour installer le plugin, se rendre dans la section <code>Accueil / Administrer Jenkins / Gestion des plugins</code>, onglet <code>Disponibles</code> (soit le chemin <code>/pluginManager/available</code> dans l'URL Jenkins) et rechercher "Active Directory" dans le champ <code>Filtre</code> :
| |
| − | :[[Fichier:ClipCapIt-200110-150820.PNG|none|thumb|300px|Plugin Active Directory]]
| |
| − | | |
| − | Cocher la cache correspondant au plugin et cliquer sur <code>Installer sans redémarrer</code> pour installer le plugin.
| |
| − | | |
| − | ==== Activation de l'authenfication AD ====
| |
| − | Une fois le plugin installé, se rendre dans la section <code>Accueil / Administrer Jenkins / Configurer la sécurité globale</code> (soit le chemin <code>/configureSecurity/</code> dans l'URL Jenkins) et cocher la case <code>Activer la sécurité</code> si ce n'est pas déjà fait.
| |
| − | | |
| − | Sélectionner ensuite <code>Active Directory</code> dans la section <code>Royaume pour la sécurité (Realm)</code> et cliquer sur <code>Add Domain</code>. Cela a pour effet de faire apparaître un formulaire à remplir. Il est possible d'ajouter plusieurs domaines :
| |
| − | :[[Fichier:ClipCapIt-200110-150853.PNG|none|thumb|300px|Formulaire domaine Active Directory]]
| |
| − | | |
| − | 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 <code>Test Domain</code> 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, <u>dans un premier temps</u>, afin d'éviter cette situation, dans la section <code>Autorisations</code>, cocher le choix <code>Tout le monde a accès à toutes les fonctionnalités</code>. 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 <code>Enregistrer</code>.
| |
| − | | |
| − | Faire un test de connexion en cliquant sur <code>S'identifier</code> en haut à droit de Jenkins :
| |
| − | :[[Fichier:ClipCapIt-200110-150915.PNG|none|thumb|300px|Authentification 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 <code>Accueil / Administrer Jenkins / Configurer la sécurité globale</code> (soit le chemin <code>/configureSecurity/</code> dans l'URL Jenkins) et cocher la case <code>Les utilisateurs connectés peuvent tout faire</code>. Ainsi, seules les personnes connectées au travers l'Active Directory pourront réaliser des actions dans Jenkins.
| |
| − | | |
| − | Valider la configuration en cliquant sur <code>Enregistrer</code>.
| |
| − | | |
| − | 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 [https://wiki.jenkins.io/display/JENKINS/Role+Strategy+Plugin Role Strategy].
| |
| − | ==== Installation du plugin Role Strategy ====
| |
| − | Pour installer le plugin, se rendre dans la section <code>Accueil / Administrer Jenkins / Gestion des plugins</code>, onglet <code>Disponibles</code> (soit le chemin <code>/pluginManager/available</code> dans l'URL Jenkins) et rechercher "Authorization Strategy" dans le champ <code>Filtre</code> :
| |
| − | :[[Fichier:ClipCapIt-200204-094658.PNG|none|thumb|300px|Plugin Role-based Authorization Strategy]]
| |
| − | | |
| − | Cocher la cache correspondant au plugin et cliquer sur <code>Installer sans redémarrer</code> pour installer le plugin.
| |
| − | | |
| − | ==== Paramétrage des rôles ====
| |
| − | ===== Menu =====
| |
| − | Une fois le plugin installé, se rendre dans la section <code>Accueil / Administrer Jenkins / Configurer la sécurité globale</code> (soit le chemin <code>/configureSecurity/</code> dans l'URL Jenkins), cocher la case <code>Stratégie basée sur les rôles</code> dans la section <code>Autorisations</code> 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 <code>Accueil / Administrer Jenkins / Gérer et assigner les rôles</code> (soit le chemin <code>/role-strategy/</code> dans l'URL Jenkins) :
| |
| − | :[[Fichier:ClipCapIt-200204-094714.PNG|none|thumb|300px|Nouvelle section "Gérer et assigner les rôles"]]
| |
| − | | |
| − | 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 [https://javadoc.jenkins.io/plugin/role-strategy/com/synopsys/arc/jenkins/plugins/rolestrategy/RoleMacroExtension.html RoleMacroExtension]
| |
| − | | |
| − | :[[Fichier:ClipCapIt-200204-094744.PNG|none|thumb|300px|Menus de la section "Gérer et assigner les rôles"]]
| |
| − | | |
| − | ===== 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 <code>Ajouter</code>. 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.
| |
| − | :[[Fichier:ClipCapIt-200204-094836.PNG|none|thumb|300px|Exemple de matrice de rôles globaux]]
| |
| − | | |
| − | *'''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 <code>Ajouter</code>. Le patron est [https://fr.wikipedia.org/wiki/Expression_r%C3%A9guli%C3%A8re 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''".
| |
| − | | |
| − | :[[Fichier:ClipCapIt-200204-094851.PNG|none|thumb|300px|Exemple de matrice de rôles de projets]]
| |
| − | | |
| − | *'''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 <code>Ajouter</code>. 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é.
| |
| − | :[[Fichier:ClipCapIt-200204-094903.PNG|none|thumb|300px|Exemple d'assignation de rôles]]
| |
| − | | |
| − | ===== 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 <code>ServiceA</code>, <code>ServiceB</code> et <code>ServiceC</code> se trouvent les projets respectifs des services en question.
| |
| − | | |
| − | Dans le dossier <code>Presta</code> 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 (<code>ServiceA</code>, <code>ServiceB</code>, <code>ServiceC</code> et <code>Presta</code>).
| |
| − | *Pour les utilisateurs travaillant sur <code>ServiceA</code>, <code>ServiceB</code> ou <code>ServiceC</code>, 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 <code>Presta</code> 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 <code>ServiceA</code>, <code>ServiceB</code> et <code>ServiceC</code>, 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 <code>Presta</code>, 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 <code>Presta</code> et se rendre à l'intérieur, rien de plus.
| |
| − | *Pour les sous-dossiers de <code>Presta</code>, 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 (<code>ServiceA</code>, <code>ServiceB</code> et <code>ServiceC</code>) ==> ''ServiceA'', ''ServiceB'' ou ''ServiceC''
| |
| − | **Groupe d'utilisateurs externes ==> ''Presta'' (obligatoire) et ''<rôle de projet de la société>'' (exemple ''SociétéExterne'')
| |
| − | | |
| − | ==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|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'' :
| |
| − | | |
| − | :[[Fichier:ClipCapIt-190813-150054.PNG|none|thumb|300px|Jenkins - Projet]]
| |
| − | | |
| − | Dans la configuration du projet, se rendre dans la section ''Environnements de Build'' et cliquer sur ''Inject environment variables to the build process'' :
| |
| − | | |
| − | :[[Fichier:ClipCapIt-190813-150116.PNG|none|thumb|300px|Jenkins - Projet - Environnements de Build]]
| |
| − | | |
| − | Dans la section précédemment ouverte, dans le champ ''Properties Content'', définir le <code>PATH</code> comme ceci : <code>/local/php/php7/bin:$PATH</code>. Dans cet exemple, le chemin des binaires PHP 7 a été mis <u>devant</u> la variable <code>$PATH</code>. 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.
| |
| − | | |
| − | :[[Fichier:ClipCapIt-190813-150136.PNG|none|thumb|300px|Jenkins - Projet - Properties Content]]
| |
| − | | |
| − | 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
| |
| − | | |
| − | :[[Fichier:ClipCapIt-190813-150205.PNG|none|thumb|300px|Jenkins - Projet - Build - Shell]]
| |
| − | | |
| − | Cliquer sur Sauver :
| |
| − | | |
| − | :[[Fichier:ClipCapIt-190813-150222.PNG|none|thumb|300px|Jenkins - Projet - Sauver]]
| |
| − | | |
| − | Lancer ensuite un build en cliquant sur ''Lancer un build'' :
| |
| − | | |
| − | :[[Fichier:ClipCapIt-190813-150240.PNG|none|thumb|300px|Jenkins - Projet - Lancer build]]
| |
| − | | |
| − | Un build supplémentaire apparaît dans la section ''Historique des builds'' :
| |
| − | | |
| − | :[[Fichier:ClipCapIt-190813-150256.PNG|none|thumb|300px|Jenkins - Projet - Historique des builds]]
| |
| − | | |
| − | Cliquer sur le dernier build puis cliquer sur ''Console Output'' pour afficher le détail :
| |
| − | | |
| − | :[[Fichier:ClipCapIt-190813-150333.PNG|none|thumb|300px|Jenkins - Projet - Détail build]]
| |
| − | | |
| − | 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''
| |
| − | | |
| − | :[[Fichier:ClipCapIt-190813-150352.PNG|none|thumb|300px|Jenkins - Projet - Build - Sortie console]]
| |
| − | | |
| − | 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'[http://myjenkinsserver:8080/manage administration Jenkins] puis dans [http://myjenkinsserver:8080/configureTools/ Configuration globale des outils].
| |
| − | | |
| − | Dans la section ''Gradle'', cliquer sur ''Ajouter Gradle'' pour ajouter une version de PHP :
| |
| − | :[[Fichier:ClipCapIt-190813-150440.PNG|none|thumb|300px|Jenkins - Ajouter Gradle]]
| |
| − | | |
| − | 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'' :
| |
| − | :[[Fichier:ClipCapIt-190813-150500.PNG|none|thumb|300px|Jenkins - Ajouter Gradle - PHP]]
| |
| − | | |
| − | 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 :
| |
| − | <syntaxhighlight lang="groovy">
| |
| − | pipeline {
| |
| − | agent any
| |
| − | tools {
| |
| − | gradle 'PHP7'
| |
| − | }
| |
| − | | |
| − | stages {
| |
| − | stage('Test appel PHP') {
| |
| − | steps {
| |
| − | sh '''
| |
| − | php -v
| |
| − | which php
| |
| − | echo $PATH
| |
| − | composer --version
| |
| − | '''
| |
| − | }
| |
| − | }
| |
| − | }
| |
| − | }
| |
| − | </syntaxhighlight>
| |
| − | | |
| − | Cela aura pour effet de produire la sortie suivante :
| |
| − | <pre>
| |
| − | ...
| |
| − | [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
| |
| − | ...
| |
| − | </pre>
| |
| − | | |
| − | ==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 (<code>$JENKINS_HOME</code>) 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 :
| |
| − | | |
| − | *<code>$JENKINS_HOME/credentials.xml</code>
| |
| − | **Ce fichier est utilisé par le plugin [https://wiki.jenkins.io/display/JENKINS/Credentials+Plugin Credentials] utilise pour stocker les informations d'identification.
| |
| − | *<code>$JENKINS_HOME/jobs/</code>
| |
| − | **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 [https://wiki.jenkins.io/display/JENKINS/Artifactory+Plugin 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 <code>$JENKINS_HOME</code> 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 <code>cat</code> ou un <code>less</code>, ou simplement via un <code>scp</code> 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 <code>credentials.xml</code>, le fichier peut contenir un extrait comme celui-ci :
| |
| − | <syntaxhighlight lang="xml">
| |
| − | <username>jenkins-user@mycompany.com</username>
| |
| − | <password>{AQAAABAAAAAgyqp9mI73xTYaYkaMRNolxwxR+X0qev7q6Hb3KcchbM9VA5ERj0RG1Nrl/aFw7haU}</password>
| |
| − | </syntaxhighlight>
| |
| − | *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 <code><password/></code> 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 :
| |
| − | <syntaxhighlight lang="xml">
| |
| − | <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>
| |
| − | </syntaxhighlight>
| |
| − | | |
| − | 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 [https://www.google.com/search?hl=en&q=com.cloudbees.plugins.credentials.impl.UsernamePasswordCredentialsImpl&aq=f&oq= moteur de recherche] pour trouver le code source. Dans ce cas précis, il suffit de chercher <code>com.cloudbees.plugins.credentials.impl.UsernamePasswordCredentialsImpl</code>.
| |
| − | | |
| − | Un rapide examen du code source fait ressortir ce [https://github.com/jenkinsci/credentials-plugin/blob/3b9555eca6cfa02fca8e5163235f5abbe057865f/src/main/java/com/cloudbees/plugins/credentials/impl/UsernamePasswordCredentialsImpl.java#L65-L73 constructeur] :
| |
| − | <syntaxhighlight lang="java">
| |
| − | @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);
| |
| − | }
| |
| − | </syntaxhighlight>
| |
| − | | |
| − | Ainsi, <code>com.cloudbees.plugins.credentials.impl.UsernamePasswordCredentialsImpl</code> utilise <code>hudson.util.Secret</code> pour chiffrer le mot de passe. Lors de la recherche suivante, le code source <code>hudson.util.Secrets</code> indique à son tour une méthode de déchiffrement :
| |
| − | <syntaxhighlight lang="java">
| |
| − | @CheckForNull
| |
| − | public static Secret decrypt(@CheckForNull String data) {
| |
| − | ...
| |
| − | }
| |
| − | </syntaxhighlight>
| |
| − | | |
| − | La classe est utilisée pour chiffrer / déchiffrer le mot de passe est donc <code>Secret</code>. 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 <code>hudson.util.Secret#déchiffrer</code> en passant le mot de passe trouvé dans <code>credentials.xml</code>. Jenkins fourni cet environnement d'exécution.
| |
| − | | |
| − | ===Utiliser la console de script pour découvrir le mot de passe===
| |
| − | Jenkins est livré avec une [http://myjenkinsserver:8080/script 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 :
| |
| − | <syntaxhighlight lang="groovy">
| |
| − | import hudson.util.Secret;
| |
| − | | |
| − | println Secret.decrypt("{AQAAABAAAAAQ5Qp/KX1Ibliy/23sM6e3Lepwa/OObLtGHC5svihnTr4=}");
| |
| − | | |
| − | // Résultat : jenkins
| |
| − | </syntaxhighlight>
| |
| − | | |
| − | Le mot de passe est ainsi retrouvé.
| |
