mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-01-10 04:05:09 -08:00
95 lines
9.3 KiB
Markdown
95 lines
9.3 KiB
Markdown
# Grundlegende Jenkins-Informationen
|
|
|
|
{{#include ../../banners/hacktricks-training.md}}
|
|
|
|
## Zugriff
|
|
|
|
### Benutzername + Passwort
|
|
|
|
Der häufigste Weg, sich in Jenkins anzumelden, ist mit einem Benutzernamen oder einem Passwort.
|
|
|
|
### Cookie
|
|
|
|
Wenn ein **autorisierter Cookie gestohlen wird**, kann er verwendet werden, um auf die Sitzung des Benutzers zuzugreifen. Der Cookie wird normalerweise `JSESSIONID.*` genannt. (Ein Benutzer kann alle seine Sitzungen beenden, muss jedoch zuerst herausfinden, dass ein Cookie gestohlen wurde).
|
|
|
|
### SSO/Plugins
|
|
|
|
Jenkins kann mit Plugins konfiguriert werden, um **über Drittanbieter-SSO** zugänglich zu sein.
|
|
|
|
### Tokens
|
|
|
|
**Benutzer können Tokens generieren**, um Anwendungen den Zugriff zu ermöglichen, um sie über CLI oder REST API zu impersonifizieren.
|
|
|
|
### SSH-Schlüssel
|
|
|
|
Diese Komponente bietet einen integrierten SSH-Server für Jenkins. Es ist eine alternative Schnittstelle für die [Jenkins CLI](https://www.jenkins.io/doc/book/managing/cli/), und Befehle können auf diese Weise mit jedem SSH-Client aufgerufen werden. (Aus den [Docs](https://plugins.jenkins.io/sshd/))
|
|
|
|
## Autorisierung
|
|
|
|
In `/configureSecurity` ist es möglich, die **Autorisierungsmethode von Jenkins** zu konfigurieren. Es gibt mehrere Optionen:
|
|
|
|
- **Jeder kann alles tun**: Sogar anonymer Zugriff kann den Server verwalten.
|
|
- **Legacy-Modus**: Gleich wie Jenkins <1.164. Wenn Sie die **"admin"-Rolle** haben, erhalten Sie **vollständige Kontrolle** über das System, und **ansonsten** (einschließlich **anonymer** Benutzer) haben Sie **Lesezugriff**.
|
|
- **Eingeloggte Benutzer können alles tun**: In diesem Modus erhält jeder **eingeloggte Benutzer vollständige Kontrolle** über Jenkins. Der einzige Benutzer, der keine vollständige Kontrolle hat, ist der **anonyme Benutzer**, der nur **Lesezugriff** erhält.
|
|
- **Matrix-basierte Sicherheit**: Sie können **konfigurieren, wer was tun kann** in einer Tabelle. Jede **Spalte** repräsentiert eine **Berechtigung**. Jede **Zeile** **repräsentiert** einen **Benutzer oder eine Gruppe/Rolle.** Dies umfasst einen speziellen Benutzer '**anonymous**', der **nicht authentifizierte Benutzer** repräsentiert, sowie '**authenticated**', der **alle authentifizierten Benutzer** repräsentiert.
|
|
|
|
.png>)
|
|
|
|
- **Projektbasierte Matrix-Autorisierungsstrategie:** Dieser Modus ist eine **Erweiterung** der "**Matrix-basierten Sicherheit**", die es ermöglicht, zusätzliche ACL-Matrizen **für jedes Projekt separat zu definieren.**
|
|
- **Rollenbasierte Strategie:** Ermöglicht die Definition von Berechtigungen mit einer **rollenbasierten Strategie**. Verwalten Sie die Rollen in `/role-strategy`.
|
|
|
|
## **Sicherheitsbereich**
|
|
|
|
In `/configureSecurity` ist es möglich, den **Sicherheitsbereich zu konfigurieren.** Standardmäßig unterstützt Jenkins einige verschiedene Sicherheitsbereiche:
|
|
|
|
- **Delegieren an den Servlet-Container**: Für **die Authentifizierung an einen Servlet-Container, der den Jenkins-Controller ausführt**, wie [Jetty](https://www.eclipse.org/jetty/).
|
|
- **Jenkins eigene Benutzerdatenbank:** Verwenden Sie **Jenkins eigene integrierte Benutzerdatenbank** zur Authentifizierung, anstatt an ein externes System zu delegieren. Dies ist standardmäßig aktiviert.
|
|
- **LDAP**: Delegieren Sie die gesamte Authentifizierung an einen konfigurierten LDAP-Server, einschließlich sowohl Benutzer als auch Gruppen.
|
|
- **Unix-Benutzer-/Gruppendatenbank**: **Delegiert die Authentifizierung an die zugrunde liegende Unix**-OS-Benutzerdatenbank auf dem Jenkins-Controller. Dieser Modus ermöglicht auch die Wiederverwendung von Unix-Gruppen für die Autorisierung.
|
|
|
|
Plugins können zusätzliche Sicherheitsbereiche bereitstellen, die nützlich sein können, um Jenkins in bestehende Identitätssysteme zu integrieren, wie zum Beispiel:
|
|
|
|
- [Active Directory](https://plugins.jenkins.io/active-directory)
|
|
- [GitHub-Authentifizierung](https://plugins.jenkins.io/github-oauth)
|
|
- [Atlassian Crowd 2](https://plugins.jenkins.io/crowd2)
|
|
|
|
## Jenkins-Knoten, Agenten & Executor
|
|
|
|
Definitionen aus den [Docs](https://www.jenkins.io/doc/book/managing/nodes/):
|
|
|
|
**Knoten** sind die **Maschinen**, auf denen die Build-**Agenten laufen**. Jenkins überwacht jeden angeschlossenen Knoten auf Speicherplatz, freien temporären Speicher, freien Swap, Uhrzeit/Synchronisation und Reaktionszeit. Ein Knoten wird offline genommen, wenn einer dieser Werte außerhalb des konfigurierten Schwellenwerts liegt.
|
|
|
|
**Agenten** **verwalten** die **Aufgabenausführung** im Auftrag des Jenkins-Controllers, indem sie **Executor** verwenden. Ein Agent kann jedes Betriebssystem verwenden, das Java unterstützt. Die für Builds und Tests erforderlichen Tools sind auf dem Knoten installiert, auf dem der Agent läuft; sie können **direkt oder in einem Container** (Docker oder Kubernetes) installiert werden. Jeder **Agent ist effektiv ein Prozess mit seiner eigenen PID** auf der Hostmaschine.
|
|
|
|
Ein **Executor** ist ein **Slot für die Ausführung von Aufgaben**; effektiv ist es **ein Thread im Agenten**. Die **Anzahl der Executor** auf einem Knoten definiert die Anzahl der **gleichzeitigen Aufgaben**, die zu einem Zeitpunkt auf diesem Knoten ausgeführt werden können. Mit anderen Worten, dies bestimmt die **Anzahl der gleichzeitigen Pipeline `stages`**, die zu einem Zeitpunkt auf diesem Knoten ausgeführt werden können.
|
|
|
|
## Jenkins-Geheimnisse
|
|
|
|
### Verschlüsselung von Geheimnissen und Anmeldeinformationen
|
|
|
|
Definition aus den [Docs](https://www.jenkins.io/doc/developer/security/secrets/#encryption-of-secrets-and-credentials): Jenkins verwendet **AES zur Verschlüsselung und zum Schutz von Geheimnissen**, Anmeldeinformationen und deren jeweiligen Verschlüsselungsschlüsseln. Diese Verschlüsselungsschlüssel werden in `$JENKINS_HOME/secrets/` zusammen mit dem Master-Schlüssel gespeichert, der zum Schutz dieser Schlüssel verwendet wird. Dieses Verzeichnis sollte so konfiguriert werden, dass nur der Betriebssystembenutzer, unter dem der Jenkins-Controller läuft, Lese- und Schreibzugriff auf dieses Verzeichnis hat (d.h. ein `chmod`-Wert von `0700` oder unter Verwendung geeigneter Dateiattribute). Der **Master-Schlüssel** (manchmal in der Kryptosprache als "Key Encryption Key" bezeichnet) wird **_unverschlüsselt_** auf dem Dateisystem des Jenkins-Controllers in **`$JENKINS_HOME/secrets/master.key`** gespeichert, was nicht vor Angreifern schützt, die direkten Zugriff auf diese Datei haben. Die meisten Benutzer und Entwickler verwenden diese Verschlüsselungsschlüssel indirekt über entweder die [Secret](https://javadoc.jenkins.io/byShortName/Secret) API zur Verschlüsselung allgemeiner geheimer Daten oder über die Anmeldeinformations-API. Für die kryptokuriosen Benutzer verwendet Jenkins AES im Cipher Block Chaining (CBC)-Modus mit PKCS#5-Padding und zufälligen IVs, um Instanzen von [CryptoConfidentialKey](https://javadoc.jenkins.io/byShortName/CryptoConfidentialKey) zu verschlüsseln, die in `$JENKINS_HOME/secrets/` mit einem Dateinamen gespeichert werden, der ihrer `CryptoConfidentialKey`-ID entspricht. Häufige Schlüssel-IDs sind:
|
|
|
|
- `hudson.util.Secret`: verwendet für allgemeine Geheimnisse;
|
|
- `com.cloudbees.plugins.credentials.SecretBytes.KEY`: verwendet für einige Anmeldeinformationstypen;
|
|
- `jenkins.model.Jenkins.crumbSalt`: verwendet vom [CSRF-Schutzmechanismus](https://www.jenkins.io/doc/book/managing/security/#cross-site-request-forgery); und
|
|
|
|
### Zugriff auf Anmeldeinformationen
|
|
|
|
Anmeldeinformationen können **globalen Anbietern** (`/credentials/`) zugewiesen werden, auf die von jedem konfigurierten Projekt zugegriffen werden kann, oder sie können auf **spezifische Projekte** (`/job/<project-name>/configure`) beschränkt werden und sind daher nur von dem spezifischen Projekt aus zugänglich.
|
|
|
|
Laut [**den Docs**](https://www.jenkins.io/blog/2019/02/21/credentials-masking/): Anmeldeinformationen, die im Geltungsbereich sind, stehen der Pipeline ohne Einschränkungen zur Verfügung. Um **versehentliche Offenlegung im Build-Protokoll** zu verhindern, werden Anmeldeinformationen **maskiert** und sind nicht im regulären Output sichtbar, sodass ein Aufruf von `env` (Linux) oder `set` (Windows) oder Programme, die ihre Umgebung oder Parameter drucken, **sie im Build-Protokoll nicht offenbaren** für Benutzer, die ansonsten keinen Zugriff auf die Anmeldeinformationen hätten.
|
|
|
|
**Deshalb muss ein Angreifer, um die Anmeldeinformationen zu exfiltrieren, sie beispielsweise base64 kodieren.**
|
|
|
|
## Referenzen
|
|
|
|
- [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}}
|