Basic Jenkins Information
Accès
Nom d'utilisateur + Mot de passe
La manière la plus courante de se connecter à Jenkins est avec un nom d'utilisateur ou un mot de passe.
Cookie
Si un cookie autorisé est volé, il peut être utilisé pour accéder à la session de l'utilisateur. Le cookie est généralement appelé JSESSIONID.*. (Un utilisateur peut mettre fin à toutes ses sessions, mais il devrait d'abord découvrir qu'un cookie a été volé).
SSO/Plugins
Jenkins peut être configuré à l'aide de plugins pour être accessible via un SSO tiers.
Jetons
Les utilisateurs peuvent générer des jetons pour donner accès aux applications pour les impersonner via CLI ou REST API.
Clés SSH
Ce composant fournit un serveur SSH intégré pour Jenkins. C'est une interface alternative pour le Jenkins CLI, et les commandes peuvent être invoquées de cette manière en utilisant n'importe quel client SSH. (À partir de la documentation)
Autorisation
Dans /configureSecurity, il est possible de configurer la méthode d'autorisation de Jenkins. Il existe plusieurs options :
Tout le monde peut tout faire : Même l'accès anonyme peut administrer le serveur.
Mode hérité : Identique à Jenkins <1.164. Si vous avez le rôle "admin", vous aurez un contrôle total sur le système, et sinon (y compris les utilisateurs anonymes), vous aurez un accès en lecture.
Les utilisateurs connectés peuvent tout faire : Dans ce mode, chaque utilisateur connecté a un contrôle total sur Jenkins. Le seul utilisateur qui n'aura pas un contrôle total est l'utilisateur anonyme, qui a seulement un accès en lecture.
Sécurité basée sur une matrice : Vous pouvez configurer qui peut faire quoi dans un tableau. Chaque colonne représente une autorisation. Chaque ligne représente un utilisateur ou un groupe/rôle. Cela inclut un utilisateur spécial 'anonyme', qui représente les utilisateurs non authentifiés, ainsi que 'authentifié', qui représente tous les utilisateurs authentifiés.
Stratégie d'autorisation basée sur une matrice basée sur le projet : Ce mode est une extension de la "sécurité basée sur une matrice" qui permet de définir des ACL supplémentaires pour chaque projet séparément.
Stratégie basée sur les rôles : Permet de définir des autorisations en utilisant une stratégie basée sur les rôles. Gérez les rôles dans
/role-strategy.
Royaume de sécurité
Dans /configureSecurity, il est possible de configurer le royaume de sécurité. Par défaut, Jenkins inclut la prise en charge de quelques royaumes de sécurité différents :
Déléguer au conteneur servlet : Pour déléguer l'authentification à un conteneur servlet exécutant le contrôleur Jenkins, tel que Jetty.
Base de données utilisateur propre à Jenkins : Utilise le magasin de données utilisateur intégré de Jenkins pour l'authentification au lieu de déléguer à un système externe. C'est activé par défaut.
LDAP : Délègue toute l'authentification à un serveur LDAP configuré, y compris les utilisateurs et les groupes.
Base de données utilisateur/groupe Unix : Délègue l'authentification à la base de données utilisateur de niveau Unix sous-jacente sur le contrôleur Jenkins. Ce mode permet également la réutilisation des groupes Unix pour l'autorisation.
Les plugins peuvent fournir des royaumes de sécurité supplémentaires qui peuvent être utiles pour incorporer Jenkins dans des systèmes d'identité existants, tels que :
Noeuds, Agents & Exécuteurs Jenkins
Définitions de la documentation :
Les noeuds sont les machines sur lesquelles les agents de construction s'exécutent. Jenkins surveille chaque noeud attaché pour l'espace disque, l'espace temporaire libre, l'espace d'échange libre, l'heure de l'horloge/synchronisation et le temps de réponse. Un noeud est mis hors ligne si l'une de ces valeurs dépasse le seuil configuré.
Les agents gèrent l'exécution des tâches au nom du contrôleur Jenkins en utilisant des exécuteurs. Un agent peut utiliser n'importe quel système d'exploitation prenant en charge Java. Les outils requis pour les constructions et les tests sont installés sur le noeud où l'agent s'exécute ; ils peuvent être installés directement ou dans un conteneur (Docker ou Kubernetes). Chaque agent est en fait un processus avec son propre PID sur la machine hôte.
Un exécuteur est un emplacement pour l'exécution des tâches ; en fait, c'est un thread dans l'agent. Le nombre d'exécuteurs sur un noeud définit le nombre de tâches concurrentes qui peuvent être exécutées sur ce noeud en même temps. En d'autres termes, cela détermine le nombre de stages de Pipeline concurrents qui peuvent s'exécuter sur ce noeud en même temps.
Secrets Jenkins
Chiffrement des Secrets et des Informations d'Identification
Définition de la documentation : Jenkins utilise AES pour chiffrer et protéger les secrets, les informations d'identification et leurs clés de chiffrement respectives. Ces clés de chiffrement sont stockées dans $JENKINS_HOME/secrets/ avec la clé principale utilisée pour protéger lesdites clés. Ce répertoire doit être configuré de sorte que seul l'utilisateur du système d'exploitation sous lequel le contrôleur Jenkins s'exécute ait un accès en lecture et en écriture à ce répertoire (c'est-à-dire une valeur chmod de 0700 ou en utilisant des attributs de fichier appropriés). La clé principale (parfois appelée "clé de chiffrement de clé" dans le jargon cryptographique) est stockée _non chiffrée_ sur le système de fichiers du contrôleur Jenkins dans $JENKINS_HOME/secrets/master.key ce qui ne protège pas contre les attaquants ayant un accès direct à ce fichier. La plupart des utilisateurs et développeurs utiliseront ces clés de chiffrement indirectement via soit l'API Secret pour chiffrer des données secrètes génériques, soit à travers l'API des informations d'identification. Pour les curieux de la cryptographie, Jenkins utilise AES en mode de chaînage de blocs (CBC) avec un rembourrage PKCS#5 et des IV aléatoires pour chiffrer les instances de CryptoConfidentialKey qui sont stockées dans $JENKINS_HOME/secrets/ avec un nom de fichier correspondant à leur ID CryptoConfidentialKey. Les ID de clé courants incluent :
hudson.util.Secret: utilisé pour les secrets génériques ;com.cloudbees.plugins.credentials.SecretBytes.KEY: utilisé pour certains types d'informations d'identification ;jenkins.model.Jenkins.crumbSalt: utilisé par le mécanisme de protection CSRF ; et
Accès aux identifiants
Les identifiants peuvent être restreints aux fournisseurs globaux (/credentials/) accessibles par tout projet configuré, ou peuvent être restreints à des projets spécifiques (/job/<nom-du-projet>/configure) et donc uniquement accessibles depuis le projet spécifique.
Selon la documentation: Les identifiants qui sont dans le champ d'application sont rendus disponibles au pipeline sans limitation. Pour éviter une exposition accidentelle dans le journal de construction, les identifiants sont masqués dans la sortie régulière, donc une invocation de env (Linux) ou set (Windows), ou des programmes imprimant leur environnement ou leurs paramètres ne les révéleraient pas dans le journal de construction aux utilisateurs qui n'auraient pas autrement accès aux identifiants.
C'est pourquoi pour exfiltrer les identifiants, un attaquant doit, par exemple, les encoder en base64.
Références
Dernière mise à jour
