Basic Jenkins Information
Accès
Nom d'utilisateur + Mot de passe
La méthode la plus courante pour 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 terminer toutes ses sessions, mais il doit 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.
Tokens
Les utilisateurs peuvent générer des tokens pour donner accès aux applications afin de les imiter 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. (D'après les docs)
Autorisation
Dans /configureSecurity, il est possible de configurer la méthode d'autorisation de Jenkins. Il existe plusieurs options :
N'importe qui 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 le 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é obtient le contrôle total de Jenkins. Le seul utilisateur qui n'aura pas le contrôle total est l'utilisateur anonyme, qui n'aura qu'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 permission. 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 de projet : Ce mode est une extension de la "sécurité basée sur une matrice" qui permet de définir une matrice ACL supplémentaire 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.
Domaine de sécurité
Dans /configureSecurity, il est possible de configurer le domaine de sécurité. Par défaut, Jenkins inclut la prise en charge de quelques domaines de sécurité différents :
Déléguer au conteneur de servlets : Pour déléguer l'authentification à un conteneur de servlets exécutant le contrôleur Jenkins, tel que Jetty.
Base de données utilisateur propre à Jenkins : Utilisez le magasin de données utilisateur intégré de Jenkins pour l'authentification au lieu de déléguer à un système externe. Ceci est activé par défaut.
LDAP : Déléguez 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 au niveau du système d'exploitation Unix sur le contrôleur Jenkins. Ce mode permettra également la réutilisation des groupes Unix pour l'autorisation.
Les plugins peuvent fournir des domaines de sécurité supplémentaires qui peuvent être utiles pour intégrer Jenkins dans des systèmes d'identité existants, tels que :
Nœuds Jenkins, Agents & Exécuteurs
Définitions des docs :
Nœuds sont les machines sur lesquelles les agents de build s'exécutent. Jenkins surveille chaque nœud attaché pour l'espace disque, l'espace temporaire libre, l'espace d'échange libre, l'heure/synchronisation de l'horloge et le temps de réponse. Un nœud est mis hors ligne si l'une de ces valeurs dépasse le seuil configuré.
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 nécessaires pour les builds et les tests sont installés sur le nœud où l'agent s'exécute ; ils peuvent être installés directement ou dans un conteneur (Docker ou Kubernetes). Chaque agent est effectivement 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 nœud définit le nombre de tâches simultanées qui peuvent être exécutées sur ce nœud à un moment donné. En d'autres termes, cela détermine le nombre de stages de pipeline simultanés qui peuvent s'exécuter sur ce nœud à un moment donné.
Secrets Jenkins
Chiffrement des secrets et des identifiants
Définition des docs : Jenkins utilise AES pour chiffrer et protéger les secrets, les identifiants 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 ces clés. Ce répertoire doit être configuré de manière à ce que seul l'utilisateur du système d'exploitation sur 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 des développeurs utiliseront ces clés de chiffrement indirectement via l'API Secret pour chiffrer des données secrètes génériques ou via l'API des identifiants. Pour les curieux de la cryptographie, Jenkins utilise AES en mode de chaînage de blocs de chiffrement (CBC) avec un remplissage 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 identifiant CryptoConfidentialKey. Les identifiants 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'identifiants ;jenkins.model.Jenkins.crumbSalt: utilisé par le mécanisme de protection CSRF ; et
Accès aux identifiants
Les identifiants peuvent être portés à des fournisseurs globaux (/credentials/) qui peuvent être accessibles par tout projet configuré, ou peuvent être portés à des projets spécifiques (/job/<project-name>/configure) et donc accessibles uniquement à partir du projet spécifique.
Selon les docs : Les identifiants qui sont dans le périmètre sont mis à disposition du pipeline sans limitation. Pour éviter une exposition accidentelle dans le journal de build, les identifiants sont masqués de la sortie régulière, de sorte qu'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 build aux utilisateurs qui n'auraient autrement pas accès aux identifiants.
C'est pourquoi, pour exfiltrer les identifiants, un attaquant doit, par exemple, les encoder en base64.
Références
Last updated
