# Basiese Jenkins-inligting

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

## Toegang

### Gebruikersnaam + Wagwoord

Die mees algemene manier om by Jenkins aan te meld is met 'n gebruikersnaam en wagwoord

### Cookie

As 'n **gemagtigde cookie gesteel word**, kan dit gebruik word om toegang tot die gebruiker se sessie te kry. Die cookie word gewoonlik `JSESSIONID.*` genoem. (’n Gebruiker kan al sy sessies beëindig, maar hy sal eers moet uitvind dat ’n cookie gesteel is).

### SSO/Plugins

Jenkins kan met plugins gekonfigureer word om **deur derdeparty SSO toeganklik te wees**.

### Tokens

**Gebruikers kan tokens genereer** om toepassings toegang te gee om namens hulle op te tree via die CLI of REST API.

### SSH Keys

Hierdie komponent verskaf 'n ingeboude SSH-bediener vir Jenkins. Dit is 'n alternatiewe koppelvlak vir die [Jenkins CLI](https://www.jenkins.io/doc/book/managing/cli/), en opdragte kan op hierdie wyse met enige SSH-kliënt uitgevoer word. (From the [docs](https://plugins.jenkins.io/sshd/))

## Outorisering

In `/configureSecurity` is dit moontlik om die **outoriseringmetode van Jenkins te konfigureer**. Daar is verskeie opsies:

- **Anyone can do anything**: Selfs anonieme toegang kan die bediener administreer
- **Legacy mode**: Dieselfde as Jenkins <1.164. As jy die **"admin" role** het, sal jy **volledige beheer** oor die stelsel ontvang, en **andersins** (insluitend **anonieme** gebruikers) sal jy **lees** toegang hê.
- **Logged-in users can do anything**: In hierdie modus kry elke **aangemelde gebruiker volle beheer** van Jenkins. Die enigste gebruiker wat nie volle beheer sal hê nie is die **anonieme gebruiker**, wat slegs **lees toegang** kry.
- **Matrix-based security**: Jy kan **wie wat kan doen** in 'n tabel konfigureer. Elke **kolom** verteenwoordig 'n **permisisie**. Elke **ry** **verteenwoordig** 'n **gebruiker of 'n groep/rol.** Dit sluit 'n spesiale gebruiker '**anonymous**' in, wat **nie-geauthentiseerde gebruikers** verteenwoordig, sowel as '**authenticated**', wat **alle geauthentiseerde gebruikers** verteenwoordig.

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

- **Project-based Matrix Authorization Strategy:** Hierdie modus is 'n **uitbreiding** van "**Matrix-based security**" wat toelaat dat addisionele ACL-matrikse **vir elke projek afsonderlik gedefinieer word.**
- **Role-Based Strategy:** Maak dit moontlik om outorisasies te definieer met 'n **rolgebaseerde strategie**. Bestuur die rolle in `/role-strategy`.

## **Sekuriteitsdomein**

In `/configureSecurity` is dit moontlik om **die security realm te konfigureer.** Standaard ondersteun Jenkins 'n paar verskillende Security Realms:

- **Delegate to servlet container**: Vir die delegasie van verifikasie aan 'n servlet container wat die Jenkins-controller uitvoer, soos [Jetty](https://www.eclipse.org/jetty/).
- **Jenkins’ own user database:** Gebruik **Jenkins se eie ingeboude gebruikersdatabasis** vir verifikasie in plaas daarvan om dit aan 'n eksterne stelsel te delegeren. Dit is standaard aangeskakel.
- **LDAP**: Delegeer alle verifikasie aan 'n gekonfigureerde LDAP-bediener, insluitend beide gebruikers en groepe.
- **Unix user/group database**: **Delegeer die verifikasie aan die onderliggende Unix** OS-vlak gebruikersdatabasis op die Jenkins-controller. Hierdie modus sal ook hergebruik van Unix-groepe vir outorisering toelaat.

Plugins kan addisionele security realms verskaf wat nuttig kan wees om Jenkins in bestaande identity systems in te sluit, soos:

- [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

Definitions from the [docs](https://www.jenkins.io/doc/book/managing/nodes/):

**Nodes** are the **machines** on which build **agents run**. Jenkins monitors each attached node for disk space, free temp space, free swap, clock time/sync and response time. A node is taken offline if any of these values go outside the configured threshold.

**Agents** **manage** the **task execution** on behalf of the Jenkins controller by **using executors**. An agent can use any operating system that supports Java. Tools required for builds and tests are installed on the node where the agent runs; they can **be installed directly or in a container** (Docker or Kubernetes). Each **agent is effectively a process with its own PID** on the host machine.

An **executor** is a **slot for execution of tasks**; effectively, it is **a thread in the agent**. The **number of executors** on a node defines the number of **concurrent tasks** that can be executed on that node at one time. In other words, this determines the **number of concurrent Pipeline `stages`** that can execute on that node at one time.

## Jenkins Sekrete

### Enkripsie van Sekrete en Credentials

Definition from the [docs](https://www.jenkins.io/doc/developer/security/secrets/#encryption-of-secrets-and-credentials): Jenkins uses **AES to encrypt and protect secrets**, credentials, and their respective encryption keys. These encryption keys are stored in `$JENKINS_HOME/secrets/` along with the master key used to protect said keys. This directory should be configured so that only the operating system user the Jenkins controller is running as has read and write access to this directory (i.e., a `chmod` value of `0700` or using appropriate file attributes). The **master key** (sometimes referred to as a "key encryption key" in cryptojargon) is **stored \_unencrypted**\_ on the Jenkins controller filesystem in **`$JENKINS_HOME/secrets/master.key`** which does not protect against attackers with direct access to that file. Most users and developers will use these encryption keys indirectly via either the [Secret](https://javadoc.jenkins.io/byShortName/Secret) API for encrypting generic secret data or through the credentials API. For the cryptocurious, Jenkins uses AES in cipher block chaining (CBC) mode with PKCS#5 padding and random IVs to encrypt instances of [CryptoConfidentialKey](https://javadoc.jenkins.io/byShortName/CryptoConfidentialKey) which are stored in `$JENKINS_HOME/secrets/` with a filename corresponding to their `CryptoConfidentialKey` id. Common key ids include:

- `hudson.util.Secret`: used for generic secrets;
- `com.cloudbees.plugins.credentials.SecretBytes.KEY`: used for some credentials types;
- `jenkins.model.Jenkins.crumbSalt`: used by the [CSRF protection mechanism](https://www.jenkins.io/doc/book/managing/security/#cross-site-request-forgery); and

### Credentials Access

Credentials can be **scoped to global providers** (`/credentials/`) that can be accessed by any project configured, or can be scoped to **specific projects** (`/job/<project-name>/configure`) and therefore only accessible from the specific project.

According to [**the docs**](https://www.jenkins.io/blog/2019/02/21/credentials-masking/): Credentials that are in scope are made available to the pipeline without limitation. To **prevent accidental exposure in the build log**, credentials are **masked** from regular output, so an invocation of `env` (Linux) or `set` (Windows), or programs printing their environment or parameters would **not reveal them in the build log** to users who would not otherwise have access to the credentials.

**Dit is hoekom, om die credentials te exfiltrate, 'n aanvaller byvoorbeeld hulle base64 moet enkodeer.**

### Secrets in plugin/job configs on disk

Moenie aanvaar dat sekrete slegs in `credentials.xml` is nie. Baie plugins bewaar sekrete in hul **eie globale XML** onder `$JENKINS_HOME/*.xml` of in per-job `$JENKINS_HOME/jobs/<JOB>/config.xml`, soms selfs in plaintext (UI masking waarborg nie enkripsie in stoorplek nie). As jy lêerstelsel-lees toegang kry, enumereer daardie XML's en soek vir voor die hand liggende geheime tags.
```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" {} \\;
```
## Verwysings

- [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}}
