# Informations de base sur Jenkins

{{#include ../../banners/hacktricks-training.md}}

## 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 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**.

### Jetons

**Les utilisateurs peuvent générer des jetons** pour donner accès aux applications afin de les usurper 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](https://www.jenkins.io/doc/book/managing/cli/), et les commandes peuvent être invoquées de cette manière en utilisant n'importe quel client SSH. (D'après les [docs](https://plugins.jenkins.io/sshd/))

## 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é obtient un contrôle total** de Jenkins. Le seul utilisateur qui n'aura pas un contrôle total est **l'utilisateur anonyme**, qui n'obtient 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**.

![](<../../images/image (149).png>)

- **Stratégie d'autorisation basée sur les projets :** Ce mode est une **extension** à "**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`.

## **Royaume de sécurité**

Dans `/configureSecurity`, il est possible de **configurer le royaume de sécurité.** Par défaut, Jenkins inclut le support de quelques royaumes 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](https://www.eclipse.org/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. Cela est activé par défaut.
- **LDAP** : Déléguer 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 sous-jacent sur le contrôleur Jenkins.** Ce mode permettra é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 intégrer Jenkins dans des systèmes d'identité existants, tels que :

- [Active Directory](https://plugins.jenkins.io/active-directory)
- [Authentification GitHub](https://plugins.jenkins.io/github-oauth)
- [Atlassian Crowd 2](https://plugins.jenkins.io/crowd2)

## Nœuds, Agents et Exécuteurs Jenkins

Définitions des [docs](https://www.jenkins.io/doc/book/managing/nodes/) :

**Les nœuds** sont les **machines** sur lesquelles les **agents de construction s'exécutent**. Jenkins surveille chaque nœud attaché pour l'espace disque, l'espace temporaire libre, l'é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é.

**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 qui prend en charge Java. Les outils nécessaires pour les constructions 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 effet, c'est **un thread dans l'agent**. Le **nombre d'exécuteurs** sur un nœud définit le nombre de **tâches concurrentes** 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 concurrentes** qui peuvent s'exécuter sur ce nœud à un moment donné.

## Secrets Jenkins

### Chiffrement des secrets et des identifiants

Définition des [docs](https://www.jenkins.io/doc/developer/security/secrets/#encryption-of-secrets-and-credentials) : 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é maître utilisée pour protéger ces 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é maître** (parfois appelée "clé de chiffrement" 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 soit l'API [Secret](https://javadoc.jenkins.io/byShortName/Secret) pour chiffrer des données secrètes génériques ou via l'API des identifiants. Pour les curieux de cryptographie, Jenkins utilise AES en mode de chaînage de blocs (CBC) avec un remplissage PKCS#5 et des IV aléatoires pour chiffrer des instances de [CryptoConfidentialKey](https://javadoc.jenkins.io/byShortName/CryptoConfidentialKey) qui sont stockées dans `$JENKINS_HOME/secrets/` avec un nom de fichier correspondant à leur id `CryptoConfidentialKey`. Les ids de clé courants incluent :

- `hudson.util.Secret` : utilisé pour des 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](https://www.jenkins.io/doc/book/managing/security/#cross-site-request-forgery) ; et

### Accès aux identifiants

Les identifiants peuvent être **étendus aux fournisseurs globaux** (`/credentials/`) qui peuvent être accessibles par tout projet configuré, ou peuvent être étendus à **des projets spécifiques** (`/job/<project-name>/configure`) et donc uniquement accessibles depuis le projet spécifique.

Selon [**les docs**](https://www.jenkins.io/blog/2019/02/21/credentials-masking/) : Les identifiants qui sont dans le champ d'application sont mis à disposition du pipeline sans limitation. Pour **prévenir une exposition accidentelle dans le journal de construction**, les identifiants sont **masqués** de 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 **révèleraient pas ces identifiants 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

- [https://www.jenkins.io/doc/book/security/managing-security/](https://www.jenkins.io/doc/book/security/managing-security/)
- [https://www.jenkins.io/doc/book/managing/nodes/](https://www.jenkins.io/doc/book/managing/nodes/)
- [https://www.jenkins.io/doc/developer/security/secrets/](https://www.jenkins.io/doc/developer/security/secrets/)
- [https://www.jenkins.io/blog/2019/02/21/credentials-masking/](https://www.jenkins.io/blog/2019/02/21/credentials-masking/)
- [https://www.jenkins.io/doc/book/managing/security/#cross-site-request-forgery](https://www.jenkins.io/doc/book/managing/security/#cross-site-request-forgery)
- [https://www.jenkins.io/doc/developer/security/secrets/#encryption-of-secrets-and-credentials](https://www.jenkins.io/doc/developer/security/secrets/#encryption-of-secrets-and-credentials)
- [https://www.jenkins.io/doc/book/managing/nodes/](https://www.jenkins.io/doc/book/managing/nodes/)

{{#include ../../banners/hacktricks-training.md}}
