Basic Jenkins Information
Last updated
Last updated
Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Der häufigste Weg, sich bei Jenkins anzumelden, ist mit einem Benutzernamen oder einem Passwort.
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).
Jenkins kann mit Plugins konfiguriert werden, um über ein Drittanbieter-SSO zugänglich zu sein.
Benutzer können Tokens generieren, um Anwendungen den Zugriff zu gewähren, um sie über CLI oder REST API zu impersonieren.
Diese Komponente bietet einen integrierten SSH-Server für Jenkins. Es ist eine alternative Schnittstelle für die Jenkins CLI, und Befehle können auf diese Weise mit jedem SSH-Client aufgerufen werden. (Aus den Docs)
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.
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.
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.
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-Ebene 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:
Definitionen aus den Docs:
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 Executoren verwenden. Ein Agent kann jedes Betriebssystem verwenden, das Java unterstützt. Werkzeuge, die für Builds und Tests erforderlich sind, werden 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.
Definition aus den Docs: 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 als "Schlüsselverschlüsselungsschlüssel" in der Kryptojargon 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 API zur Verschlüsselung generischer 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 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 generische Geheimnisse;
com.cloudbees.plugins.credentials.SecretBytes.KEY: verwendet für einige Anmeldeinformationstypen;
jenkins.model.Jenkins.crumbSalt: verwendet vom CSRF-Schutzmechanismus; und
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: 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 in der regulären Ausgabe sichtbar, sodass ein Aufruf von env (Linux) oder set (Windows) oder Programme, die ihre Umgebung oder Parameter drucken, sie nicht im Build-Protokoll offenbaren für Benutzer, die sonst keinen Zugriff auf die Anmeldeinformationen hätten.
Deshalb muss ein Angreifer, um die Anmeldeinformationen zu exfiltrieren, sie beispielsweise base64 kodieren.
Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
