Basic Jenkins Information
Zugriff
Benutzername + Passwort
Die häufigste Methode, sich bei 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, aber er müsste zuerst herausfinden, dass ein Cookie gestohlen wurde).
SSO/Plugins
Jenkins kann so konfiguriert werden, dass es über Drittanbieter-SSO zugänglich ist, indem Plugins verwendet werden.
Tokens
Benutzer können Tokens generieren, um Anwendungen Zugriff zu gewähren, sie über CLI oder REST API zu imitieren.
SSH-Schlüssel
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 Dokumentationen)
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 administrieren.
Legacy-Modus: Gleich wie Jenkins <1.164. Wenn du die "admin"-Rolle hast, erhältst du volle Kontrolle über das System, und ansonsten (einschließlich anonymer Benutzer) hast du Lesezugriff.
Eingeloggte Benutzer können alles tun: In diesem Modus erhält jeder eingeloggte Benutzer volle Kontrolle über Jenkins. Der einzige Benutzer, der keine volle Kontrolle hat, ist der anonyme Benutzer, der nur Lesezugriff erhält.
Matrix-basierte Sicherheit: Du kannst 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 schließt einen speziellen Benutzer 'anonym' ein, der nicht authentifizierte Benutzer repräsentiert, sowie 'authentifiziert', 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 Autorisierungen mithilfe einer rollenbasierten Strategie. Verwalte 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 Servlet-Container: Zum Delegieren der Authentifizierung an einen Servlet-Container, der den Jenkins-Controller ausführt, wie Jetty.
Jenkins’ eigene Benutzerdatenbank: Verwende Jenkins’ eigenen integrierten Benutzerdatenspeicher zur Authentifizierung anstelle der Delegation an ein externes System. Dies ist standardmäßig aktiviert.
LDAP: Delegiere alle Authentifizierungen 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:
Jenkins Nodes, Agents & Executors
Definitionen aus den Dokumentationen:
Nodes sind die Maschinen, auf denen Build-Agents laufen. Jenkins überwacht jeden angeschlossenen Node auf Festplattenspeicher, freien temporären Speicher, freien Swap, Uhrzeit/Synchronisation und Antwortzeit. Ein Node wird offline genommen, wenn einer dieser Werte außerhalb des konfigurierten Schwellenwerts liegt.
Agents verwalten die Aufgabenausführung im Auftrag des Jenkins-Controllers durch Verwendung von Executors. Ein Agent kann jedes Betriebssystem verwenden, das Java unterstützt. Werkzeuge, die für Builds und Tests erforderlich sind, werden auf dem Node 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 eigener PID auf der Host-Maschine.
Ein Executor ist ein Slot für die Ausführung von Aufgaben; effektiv ist es ein Thread im Agent. Die Anzahl der Executors auf einem Node definiert die Anzahl der gleichzeitigen Aufgaben, die auf diesem Node zu einem Zeitpunkt ausgeführt werden können. Mit anderen Worten, dies bestimmt die Anzahl der gleichzeitigen Pipeline-stages, die zu einem Zeitpunkt auf diesem Node ausgeführt werden können.
Jenkins Secrets
Verschlüsselung von Secrets und Anmeldeinformationen
Definition aus den Dokumentationen: Jenkins verwendet AES zur Verschlüsselung und zum Schutz von Secrets, Anmeldeinformationen und deren jeweiligen Verschlüsselungsschlüsseln. Diese Verschlüsselungsschlüssel werden in $JENKINS_HOME/secrets/ zusammen mit dem Master-Schlüssel gespeichert, der verwendet wird, um diese Schlüssel zu schützen. 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 die Verwendung geeigneter Dateiattribute). Der Master-Schlüssel (manchmal in der Kryptojargon als "Key Encryption Key" bezeichnet) wird unverschlüsselt auf dem Jenkins-Controller-Dateisystem in $JENKINS_HOME/secrets/master.key gespeichert, was keinen Schutz gegen Angreifer bietet, 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 Anmeldeinformationen-API. Für die Kryptoneugierigen verwendet Jenkins AES im Cipher Block Chaining (CBC)-Modus mit PKCS#5-Padding und zufälligen IVs zur Verschlüsselung von Instanzen von CryptoConfidentialKey, die in $JENKINS_HOME/secrets/ mit einem Dateinamen gespeichert werden, der ihrer CryptoConfidentialKey-ID entspricht. Häufige Schlüssel-IDs umfassen:
hudson.util.Secret: verwendet für generische Secrets;com.cloudbees.plugins.credentials.SecretBytes.KEY: verwendet für einige Anmeldeinformationstypen;jenkins.model.Jenkins.crumbSalt: verwendet vom CSRF-Schutzmechanismus; und
Zugriff auf Anmeldeinformationen
Anmeldeinformationen können globalen Anbietern (/credentials/) zugeordnet werden, die von jedem konfigurierten Projekt aus zugänglich sind, oder sie können spezifischen Projekten (/job/<project-name>/configure) zugeordnet werden und sind daher nur von dem spezifischen Projekt aus zugänglich.
Laut den Dokumentationen: Anmeldeinformationen, die im Geltungsbereich sind, werden der Pipeline ohne Einschränkung zur Verfügung gestellt. Um eine versehentliche Offenlegung im Build-Log zu verhindern, werden Anmeldeinformationen maskiert aus der regulären Ausgabe, sodass ein Aufruf von env (Linux) oder set (Windows) oder Programme, die ihre Umgebung oder Parameter drucken, sie nicht im Build-Log 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.
Referenzen
Last updated
