Une fois que vous avez défini comment identifier vos utilisateurs, vous devez décider ce qu'ils sont autorisés à faire. Jenkins supporte différentes stratégies dans ce domaine, allant d'une simple approche où un utilisateur connecté peut faire n'importe quoi à des stratégies impliquant des rôles plus précis et des authentifications par projet.
Laisser les utilisateurs connectés faire n'importe quoi est certainement flexible, et pourrait suffire pour une petite équipe. Pour des équipes plus importantes ou multiples, ou des cas où Jenkins est utilisé en dehors d'un environnement de développement, une approche plus sophistiquée est généralement requise.
La sécurité basée sur matrice est une approche plus élaborée, où différents utilisateurs se voient attribuer différents droits, en utilisant une approche basée sur les rôles.
La première étape dans la configuration de la sécurité basée sur une matrice dans Jenkins est de créer un administrateur. C'est une étape essentielle, et elle doit être effectuée avant toutes les autres. Votre administrateur peut être un utilisateur existant, ou un créé spécialement dans ce but. Si vous voulez créer un utilisateur administrateur dédié, créez le simplement en vous enregistrant de la façon habituelle (voir Figure 7.2, “La page de connexion Jenkins”). Il n'est pas nécessaire qu'il soit associé à un utilisateur SCM.
Une fois que votre utilisateur administrateur est prêt, vous pouvez activer la sécurité basée sur une matrice en sélectionnant “Sécurité basée sur une matrice” dans la section Autorisations de la page de configuration principale. Jenkins affichera un tableau contenant les utilisateurs autorisés, et des cases à cocher correspondant aux différentes permissions que vous pouvez affecter à ces utilisateurs (voir Figure 7.16, “Sécurité basée sur une matrice”).
L'utilisateur spécial “anonyme” est toujours présent dans le tableau. Cet utilisateur représente les utilisateurs non authentifiés. Typiquement, vous ne donnez que des droits limités aux utilisateurs non authentifiés, comme des accès en lecture seule, ou pas d'accès du tout (comme montré dans Figure 7.16, “Sécurité basée sur une matrice”).
La première chose que vous devez savoir faire maintenant est de donner les droits d'administration à votre administrateur. Ajoutez cet utilisateur d'administration dans le champ “Utilisateur/groupe à ajouter” et cliquez sur Ajouter. Votre administrateur apparaîtra alors dans la matrice de permissions. Maintenant assurez-vous d'accorder toutes les permissions à cet utilisateur (voir Figure 7.17, “Configurer un administrateur”), et sauvez votre configuration. Vous devriez à présent être capable de vous connecter avec votre compte utilisateur administrateur (si vous n'êtes pas déjà connecté avec ce compte) et continuer à configurer vos autres utilisateurs.
Une fois que vous avez configuré votre compte administrateur, vous pouvez ajouter d'autres utilisateurs ayant besoin d'accéder à votre instance Jenkins. Ajoutez simplement les noms d'utilisateur et cochez les permissions que vous voulez leur accorder (voir Figure 7.18, “Configurer les autres utilisateurs”). Si vous utilisez un serveur LDAP ou des utilisateurs ou groupes Unix comme schéma d'authentification sous-jacent (voir Section 7.4.2, “Utiliser un annuaire LDAP”), vous pouvez aussi configurer les permissions pour des groupes d'utilisateurs.
Vous pouvez accorder différentes permissions, qui sont organisées en plusieurs groupes : Global, Esclave, Job, Lancer, Voir et Gestion de version. La plupart des permissions sont assez évidentes, mais certaines nécessitent un peu plus d'explication. Les permissions individuelles sont comme suit :
- Global
-
Ce groupe couvre des permissions basiques sur l'ensemble du système :
- Administrer
-
Permet à un utilisateur de faire des modifications de configuration à l'ensemble du système ou autres opérations sensibles, par exemple dans les pages de configuration principales de Jenkins. Ceci devrait être réservé à l'administrateur Jenkins.
- Lire
-
Cette permission fournit un accès en lecture seule à pratiquement toutes les pages de Jenkins. Si vous voulez que les utilisateurs anonymes puissent voir les tâches librement, mais qu'ils ne puissent pas les modifier ou les démarrer, donnez le droit Lire à l'utilisateur spécial “anonyme”. Sinon, enlevez simplement cette permission à l'utilisateur Anonyme. Et si vous voulez que tous les utilisateurs authentifiés puissent voir les tâches de build, ajoutez alors un utilisateur spécial “authenticated”, et donnez lui la permission Global/Lire.
- Esclave
-
Ce groupe couvre des permissions à propos de noeuds de constructions, ou esclaves :
- Configurer
-
Créer ou configurer de nouveaux noeuds de construction.
- Supprimer
-
Supprimer des noeuds de construction.
- Job
-
Ce group couvre des permissions liées aux tâches :
- Créer
-
Créer une nouvelle tâche de build.
- Supprimer
-
Supprimer une tâche de build existante.
- Configurer
-
Mettre à jour la configuration de tâches de build existantes.
- Lire
-
Voir des tâches de build.
- Build
-
Démarrer une tâche de build.
- Espace de travail
-
Voir et télécharger le contenu de l'espace de travail pour une tâche de build. Rappelez-vous, l'espace de travail contient le code source et les artefacts, donc si vous voulez protéger ces derniers d'un accès général, vous devriez enlever cette permission.
- Release
-
Démarrer une release Maven pour un projet configuré avec le plugin M2Release.
- Lancer
-
Ce groupe couvre les droits relatifs à des builds spécifiques de l'historique des builds :
- Supprimer
-
Supprimer un build de l'historique de build.
- Mettre à jour
-
Mettre à jour la description et d'autres propriétés d'un build dans l'historique de build. Ceci peut être utile si un utilisateur veut laisser une note sur la cause des échecs de build, par exemple.
- Voir
-
Ce groupe couvre des vues de gestion :
- Créer
-
Créer une nouvelle vue.
- Supprimer
-
Supprimer une vue existante.
- Configurer
-
Configurer une vue existante.
- Gestion de version
-
Permissions relatives à votre système de contrôle de version :
- Tag
-
Créer un nouveau tag dans le dépôt de code source pour un build donné.
- Autres
-
Il peut y avoir d'autres permissions disponibles, en fonction des plugins installés. Une permission utile est :
- Promouvoir
-
Si le plugin Promoted Builds est installé, cette permission permet aux utilisateurs de promouvoir manuellement un build.
Il pourrait arriver que, pendant ce processus, vous vous
bloquiez tout seul l'accès à Jenkins. Ceci peut arriver si, par
exemple, vous sauvez la configuration matricielle sans avoir
correctement configuré votre administrateur. Si cela arrive, ne
paniquez pas — il y a une correction simple, du moment que vous avez
accès au répertoire racine de Jenkins. Ouvrez simplement le fichier
config.xml à la racine du
répertoire de Jenkins. Il contiendra quelque chose de ce genre
:
<hudson>
<version>1.391</version>
<numExecutors>2</numExecutors>
<mode>NORMAL</mode>
<useSecurity>true</useSecurity>
...La chose à rechercher est l'élement
<useSecurity>. Pour restaurer votre accès à
Jenkins, changez cette valeur à false, et redémarrez votre serveur.
Vous pourrez alors à nouveau accéder à Jenkins, et mettre en place
votre configuration de sécurité correctement.
La sécurité basée sur le projet vous permet d'utiliser le modèle de sécurité matricielle dont vous venons de discuter, et l'appliquer à des projets individuels. Non seulement vous pouvez assigner des rôles globaux à vos utilisateurs, mais vous pouvez aussi configurer des droits plus spécifiques à certains projets en particulier.
Pour activer la sécurité de niveau projet, sélectionnez “Stratégie d'autorisation matricielle basée sur les projets” dans la section Autorisations de l'écran de configuration principal (voir Figure 7.19, “Sécurité basée sur le projet”). Ici, vous pouvez configurer des droits par défaut pour les utilisateurs et les groupes, comme nous l'avons vu dans la sécurité basée sur une matrice (voir Section 7.5.1, “Sécurité basée sur une matrice”).
Ce sont les permissions par défaut à appliquer à tous les projets qui n'ont pas été spécifiquement configurés. Toutefois, quand vous utilisez la sécurité basée sur le projet, vous pouvez aussi positionner des permissions spécifiques au projet. Pour faire cela, sélectionnez “Activer la sécurité basée sur le projet” dans l'écran de configuration du projet (voir Figure 7.20, “Configurer la sécurité basée sur le projet”). Jenkins affichera un tableau de permissions spécifiques au projet. Vous pouvez configurer ces permissions pour différents utilisateurs et groupes comme dans la page de configuration globales. Ces permissions seront ajoutées aux permissions globales pour produire un ensemble de permissions spécifiquement applicables à ce projet.
Comprendre comment cela fonctionne est plus facile avec quelques exemples pratiques. Dans Figure 7.19, “Sécurité basée sur le projet”, par exemple, aucune permission n'a été donnée à l'utilisateur anonyme. Donc, par défaut, toutes les tâches de build resteront invisibles jusqu'à ce que l'utilisateur se connecte. Toutefois, nous utilisons une sécurité basée sur le projet, nous pouvons donc redéfinir cela projet par projet. Dans Figure 7.20, “Configurer la sécurité basée sur le projet”, par exemple, nous avons configuré le projet game-of-life pour qu'il offre l'accès en lecture seule à l'utilisateur spécial “anonyme”.
Quand vous aurez sauvé cette configuration, les utilisateurs non authentifiés pourront voir le projet game-of-life en mode lecture seule (voir Figure 7.21, “Voir un projet”). Le même principe s'applique avec toutes les permissions spécifiques au projet.
Notez que les permissions sont cumulatives — à l'écriture de ces lignes, il n'y a pas de moyen d'enlever une permission globale pour un projet particulier. Par exemple, si l'utilisateur anonyme a l'accès en lecture seule au niveau global, vous ne pouvez pas lui enlever pour un projet individuel. Donc quand vous utilisez la sécurité basée sur le projet, utilisez la matrice globale au système pour définir des permissions par défaut minimales à travers tous vos projets, et configurez les projets avec des autorisations additionnelles spécifiques au projet.
Il y a plusieurs approches pour gérer les permissions de projet, et elles dépendent autant sur la culture organisationnelle que sur des considérations techniques. Une stratégie courante est d'autoriser les membres de l'équipe à avoir l'accès complet à leurs propres projets, et l'accès en lecture seule aux autres projets. Le plugin Extended Read Permission est une extension utile à avoir dans ce scénario. Ce plugin vous permet d'offrir aux utilisateurs d'autres équipes une vue en lecture seule de la configuration de votre projet, sans avoir à modifier quoi que ce soit (voir Figure 7.22, “Configurer les permissions de droit de lecture étendus”). C'est un formidable moyen de partager des pratiques de configuration de build et des astuces avec d'autres équipes sans les laisser trafiquer vos builds.
Il est intéressant de noter que, aussi importantes ou multiples que soient les équipes impliquées, la base de données interne de Jenkins atteint ses limites assez rapidement, et cela vaut le coup d'envisager l'intégration avec un service d'annuaire plus spécialisé comme un serveur LDAP, Active Directory ou Atlassian Crowd, ou alors un système de permission plus sophistiqué comme une sécurité basée sur les rôles, discutée dans la section suivante.
Quelques fois, gérer les permissions utilisateur individuellement peut s'avérer rébarbatif, et vous pourriez ne pas vouloir vous intégrer avec un serveur LDAP pour configurer vos groupes avec. Une alternative plus récente est d'utiliser le plugin Role Strategy, qui permet de définir des rôles globaux ou de niveau projet, et les affecter aux utilisateurs.
Vous installez le plugin de façon habituelle, via le gestionnaire de plugin. Une fois installé, vous pouvez activer cette stratégie d'autorisation sur la page de configuration principale (voir Figure 7.23, “Configurer la sécurité basée sur les rôles”).
Quand vous avez configuré cela, vous pouvez définir des rôles regroupant des ensembles de permissions liées les unes aux autres. Vous créez et configurez vos rôles, puis les assignez à vos utilisateurs, dans l'écran de gestion de rôles, auquel vous accédez dans l'écran Administrer Jenkins (voir Figure 7.24, “Le menu de configuration Gérer les rôles”).
Dans l'écran Gérer les rôles, vous pouvez mettre en place des permissions globales ou de niveau projet. Les permissions globales s'appliquent à tous les projets, et sont typiquement des permissions d'administration du système ou d'accès général (voir Figure 7.25, “Gérer les rôles globaux”). La mise en oeuvre de ces rôles est intuitive et similaire à la configuration des permissions utilisateur dans les autres modèles de securité que nous avons vus.
Les rôles de projet sont légèrement plus compliqués. Un rôle de projet regroupe un ensemble de permissions applicables à un ou plusieurs projets (a priori reliés). Vous définissez les projets concernés en utilisant une expression régulière, cela aide à avoir un ensemble clair et cohérernt de conventions de nommage dans vos noms de projets (voir Figure 7.26, “Gérer les rôles de projets”). Par exemple, vous pouvez vouloir créer des rôles distinguant les développeurs avec des droits complets sur leurs propres projets d'utilisateur qui peuvent simplement déclencher un build et voir le résultat. Ou vous pouvez créer des rôles où les développeurs peuvent configurer certaines tâches de build de déploiement automatisé, mais que seules les équipes de production soient autorisées à exécuter ces tâches.
Une fois ces rôles définis, vous pouvez aller dans l'écran Assigner les rôles pour configurer les utilisateurs ou groupes avec ces rôles (voir Figure 7.27, “Assigner des rôles à des utilisateurs”).
La stratégie basée sur les rôles est relativement nouvelle dans Jenkins, mais c'est une excellente façon de simplifier les tâches de gestion des permissions dans de grosses organisations, multi-équipes et multi-projets.