# Informazioni di base su Jenkins

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

## Accesso

### Nome utente + Password

Il modo più comune per effettuare il login in Jenkins è usare un nome utente e una password

### Cookie

Se un **cookie autorizzato viene rubato**, può essere usato per accedere alla sessione dell'utente. Il cookie di solito si chiama `JSESSIONID.*`. (Un utente può terminare tutte le sue sessioni, ma deve prima scoprire che un cookie è stato rubato).

### SSO/Plugins

Jenkins può essere configurato tramite plugin per essere **accessibile tramite SSO di terze parti**.

### Tokens

**Gli utenti possono generare token** per consentire ad applicazioni di impersonarli via CLI o REST API.

### SSH Keys

Questo componente fornisce un server SSH integrato per Jenkins. È un'interfaccia alternativa per la [Jenkins CLI](https://www.jenkins.io/doc/book/managing/cli/), e i comandi possono essere invocati in questo modo usando qualsiasi client SSH. (From the [docs](https://plugins.jenkins.io/sshd/))

## Autorizzazione

In `/configureSecurity` è possibile **configurare il metodo di autorizzazione di Jenkins**. Ci sono diverse opzioni:

- **Anyone can do anything**: Anche l'accesso anonimo può amministrare il server
- **Legacy mode**: Come Jenkins <1.164. Se hai il ruolo **"admin"**, ti verrà concesso il **controllo completo** sul sistema, e **altrimenti** (inclusi gli utenti **anonymous**) avrai accesso in **sola lettura**.
- **Logged-in users can do anything**: In questa modalità, ogni **utente autenticato ottiene il controllo completo** di Jenkins. L'unico utente che non avrà il controllo completo è **anonymous user**, che ottiene solo **accesso in sola lettura**.
- **Matrix-based security**: Puoi configurare **chi può fare cosa** in una tabella. Ogni **colonna** rappresenta un **permesso**. Ogni **riga** rappresenta un **utente o un gruppo/ruolo.** Questo include un utente speciale '**anonymous**', che rappresenta **utenti non autenticati**, così come '**authenticated**', che rappresenta **tutti gli utenti autenticati**.

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

- **Project-based Matrix Authorization Strategy:** Questa modalità è un'**estensione** di "**Matrix-based security**" che permette di definire matrici ACL aggiuntive **per ogni progetto separatamente.**
- **Role-Based Strategy:** Consente di definire autorizzazioni usando una **role-based strategy**. Gestisci i ruoli in `/role-strategy`.

## **Security Realm**

In `/configureSecurity` è possibile **configurare il security realm.** Per impostazione predefinita Jenkins include il supporto per alcuni Security Realm differenti:

- **Delegate to servlet container**: Per **delegare l'autenticazione a un servlet container che esegue il controller Jenkins**, come [Jetty](https://www.eclipse.org/jetty/).
- **Jenkins’ own user database:** Usa il **database utenti integrato di Jenkins** per l'autenticazione invece di delegare a un sistema esterno. Questo è abilitato di default.
- **LDAP**: Delega tutta l'autenticazione a un server LDAP configurato, inclusi utenti e gruppi.
- **Unix user/group database**: **Delega l'autenticazione al database utenti a livello OS Unix** sul controller Jenkins. Questa modalità permette anche il riuso dei gruppi Unix per l'autorizzazione.

I plugin possono fornire Security Realm aggiuntivi che possono essere utili per integrare Jenkins in sistemi di identity esistenti, come:

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

## Jenkins Nodes, Agents & Executors

Definizioni dalle [docs](https://www.jenkins.io/doc/book/managing/nodes/):

**Nodes** sono le **macchine** su cui girano gli **agent di build**. Jenkins monitora ogni nodo connesso per spazio su disco, spazio temporaneo libero, swap libero, ora/sincronizzazione dell'orologio e tempo di risposta. Un nodo viene messo offline se uno di questi valori supera le soglie configurate.

**Agents** gestiscono l'**esecuzione dei task** per conto del controller Jenkins **usando executors**. Un agent può usare qualsiasi sistema operativo che supporti Java. Gli strumenti necessari per build e test sono installati sul nodo dove l'agent gira; possono **essere installati direttamente o in un container** (Docker o Kubernetes). Ogni **agent è effettivamente un processo con il proprio PID** sulla macchina host.

Un **executor** è uno **slot per l'esecuzione dei task**; in pratica è **un thread nell'agent**. Il **numero di executors** su un nodo definisce il numero di **task concorrenti** che possono essere eseguiti su quel nodo contemporaneamente. In altre parole, questo determina il **numero di concurrent Pipeline `stages`** che possono essere eseguiti su quel nodo contemporaneamente.

## Segreti di Jenkins

### Encryption of Secrets and Credentials

Definizione dalle [docs](https://www.jenkins.io/doc/developer/security/secrets/#encryption-of-secrets-and-credentials): Jenkins usa **AES per criptare e proteggere secrets**, credentials e le rispettive chiavi di crittografia. Queste chiavi di crittografia sono memorizzate in `$JENKINS_HOME/secrets/` assieme alla master key usata per proteggere tali chiavi. Questa directory dovrebbe essere configurata in modo che solo l'utente del sistema operativo con cui gira il controller Jenkins abbia accesso in lettura e scrittura a questa directory (es., un valore di `chmod` pari a `0700` o usando attributi file appropriati). La **master key** (talvolta indicata come "key encryption key" in gergo crittografico) è **stored \_unencrypted**\_ nel filesystem del controller Jenkins in **`$JENKINS_HOME/secrets/master.key`**, il che non protegge dagli attaccanti con accesso diretto a quel file. La maggior parte degli utenti e sviluppatori userà queste chiavi di crittografia indirettamente tramite l'API [Secret](https://javadoc.jenkins.io/byShortName/Secret) per criptare dati segreti generici o tramite le credentials API. Per i criptocuriosi, Jenkins usa AES in modalità cipher block chaining (CBC) con padding PKCS#5 e IV casuali per criptare istanze di [CryptoConfidentialKey](https://javadoc.jenkins.io/byShortName/CryptoConfidentialKey) che sono memorizzate in `$JENKINS_HOME/secrets/` con un nome file corrispondente al loro `CryptoConfidentialKey` id. Gli id di chiave comuni includono:

- `hudson.util.Secret`: usato per secrets generici;
- `com.cloudbees.plugins.credentials.SecretBytes.KEY`: usato per alcuni tipi di credentials;
- `jenkins.model.Jenkins.crumbSalt`: usato dal [CSRF protection mechanism](https://www.jenkins.io/doc/book/managing/security/#cross-site-request-forgery); e

### Accesso alle Credentials

Le credentials possono essere **associate a provider globali** (`/credentials/`) accessibili da qualsiasi progetto configurato, oppure possono essere limitate a **progetti specifici** (`/job/<project-name>/configure`) e quindi accessibili solo dal progetto specifico.

Secondo [**the docs**](https://www.jenkins.io/blog/2019/02/21/credentials-masking/): Le credentials che sono in scope sono rese disponibili alla pipeline senza limitazioni. Per **prevenire l'esposizione accidentale nel log di build**, le credentials vengono **mascherate** dall'output normale, quindi un'invocazione di `env` (Linux) o `set` (Windows), o programmi che stampano il loro environment o i parametri **non le riveleranno nel log di build** a utenti che altrimenti non avrebbero accesso alle credentials.

**Ecco perché, per esfiltrare le credentials, un attaccante deve, per esempio, codificarle in base64.**

### Secrets in plugin/job configs on disk

Non presumere che i secrets siano presenti solo in `credentials.xml`. Molti plugin persistono secrets nel loro **proprio XML globale** sotto `$JENKINS_HOME/*.xml` o nel per-job `$JENKINS_HOME/jobs/<JOB>/config.xml`, a volte anche in chiaro (il masking nell'interfaccia utente non garantisce la memorizzazione crittografata). Se ottieni accesso in lettura al filesystem, enumera quegli XML e cerca tag ovvi che contengano secrets.
```bash
# Global plugin configs
ls -l /var/lib/jenkins/*.xml
grep -R "password\\|token\\|SecretKey\\|credentialId" /var/lib/jenkins/*.xml

# Per-job configs
find /var/lib/jenkins/jobs -maxdepth 2 -name config.xml -print -exec grep -H "password\\|token\\|SecretKey" {} \\;
```
## Riferimenti

- [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/)
- [https://www.nccgroup.com/research-blog/story-of-a-hundred-vulnerable-jenkins-plugins/](https://www.nccgroup.com/research-blog/story-of-a-hundred-vulnerable-jenkins-plugins/)

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