Basic Jenkins Information
Zugriff
Benutzername + Passwort
Der häufigste Weg, 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, müsste jedoch zuerst herausfinden, dass ein Cookie gestohlen wurde).
SSO/Plugins
Jenkins kann mithilfe von Plugins konfiguriert werden, um über ein Drittanbieter-SSO zugänglich zu sein.
Tokens
Benutzer können Tokens generieren, um Anwendungen den Zugriff zu ermöglichen, sie über die CLI oder die REST-API zu vertreten.
SSH-Schlüssel
Dieser Bestandteil 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 unter Verwendung eines beliebigen SSH-Clients aufgerufen werden. (Aus den Dokumenten)
Autorisierung
In /configureSecurity ist es möglich, die Autorisierungsmethode von Jenkins zu konfigurieren. Es gibt mehrere Optionen:
Jeder kann alles tun: Selbst anonymer Zugriff kann den Server verwalten.
Legacy-Modus: Gleich wie Jenkins <1.164. Wenn Sie die Rolle "admin" haben, erhalten Sie volle Kontrolle über das System, andernfalls (einschließlich anonymer Benutzer) haben Sie nur Lesezugriff.
Angemeldete Benutzer können alles tun: In diesem Modus erhält jeder angemeldete Benutzer die volle Kontrolle über Jenkins. Der einzige Benutzer, der keine volle Kontrolle hat, ist der anonyme Benutzer, der nur Lesezugriff erhält.
Matrixbasierte Sicherheit: Sie können in einer Tabelle konfigurieren, wer was tun kann. Jede Spalte repräsentiert eine Berechtigung. Jede Zeile repräsentiert einen Benutzer oder eine Gruppe/Rolle. Dies beinhaltet einen speziellen Benutzer 'anonym', der nicht authentifizierte Benutzer repräsentiert, sowie 'authentifiziert', der alle authentifizierten Benutzer repräsentiert.
Projektbasierte Matrix-Autorisierungsstrategie: Dieser Modus ist eine Erweiterung der "Matrixbasierten Sicherheit", die es ermöglicht, für jedes Projekt separat zusätzliche ACL-Matrizen zu definieren.
Rollenbasierte Strategie: Ermöglicht die Definition von Autorisierungen mithilfe 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 verschiedene Sicherheitsbereiche:
An Servlet-Container delegieren: Zur Delegierung der Authentifizierung an einen Servlet-Container, der den Jenkins-Controller ausführt, wie Jetty.
Jenkins eigene Benutzerdatenbank: Verwenden Sie Jenkins eigene integrierte Benutzerdatenbank zur Authentifizierung anstelle der Delegierung an ein externes System. Dies ist standardmäßig aktiviert.
LDAP: Delegiert die gesamte Authentifizierung an einen konfigurierten LDAP-Server, einschließlich Benutzern und Gruppen.
Unix-Benutzer-/Gruppendatenbank: Delegiert die Authentifizierung an die zugrunde liegende Unix-Betriebssystemebene 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 z.B.:
Jenkins-Nodes, Agenten & Ausführer
Definitionen aus den Dokumenten:
Nodes sind die Maschinen, auf denen Build-Agenten ausgeführt werden. 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.
Agenten verwalten die Aufgabenausführung im Auftrag des Jenkins-Controllers durch Verwendung von Ausführern. Ein Agent kann jedes Betriebssystem verwenden, das Java unterstützt. Tools, 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 seiner eigenen PID auf dem Hostrechner.
Ein Ausführer ist ein Slot zur Ausführung von Aufgaben; effektiv ist es ein Thread im Agenten. Die Anzahl der Ausführer auf einem Node definiert die Anzahl der gleichzeitigen Aufgaben, die auf diesem Node gleichzeitig ausgeführt werden können. Mit anderen Worten bestimmt dies die Anzahl der gleichzeitigen Pipeline-Stages, die auf diesem Node gleichzeitig ausgeführt werden können.
Jenkins-Geheimnisse
Verschlüsselung von Geheimnissen und Anmeldeinformationen
Definition aus den Dokumenten: Jenkins verwendet AES zur Verschlüsselung und zum Schutz von Geheimnissen, Anmeldeinformationen und den entsprechenden Verschlüsselungsschlüsseln. Diese Verschlüsselungsschlüssel werden in $JENKINS_HOME/secrets/ zusammen mit dem Master-Key, der zum Schutz dieser Schlüssel verwendet wird, gespeichert. Dieses Verzeichnis sollte so konfiguriert sein, dass nur der Betriebssystembenutzer, unter dem der Jenkins-Controller ausgeführt wird, Lese- und Schreibzugriff auf dieses Verzeichnis hat (d.h. ein chmod-Wert von 0700 oder die Verwendung geeigneter Dateiattribute). Der Master-Key (manchmal auch 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 werden diese Verschlüsselungsschlüssel indirekt über die Secret-API zur Verschlüsselung generischer Geheimdaten oder über die Anmeldeinformations-API verwenden. Für die Kryptobegeisterten 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 entsprechend ihrer CryptoConfidentialKey-ID gespeichert sind. Häufige Schlüssel-IDs sind:
hudson.util.Secret: verwendet für generische Geheimnisse;com.cloudbees.plugins.credentials.SecretBytes.KEY: verwendet für einige Arten von Anmeldeinformationen;jenkins.model.Jenkins.crumbSalt: verwendet vom CSRF-Schutzmechanismus; und
Zugriff auf Anmeldedaten
Anmeldeinformationen können auf globale Anbieter (/credentials/) beschränkt sein, die von jedem konfigurierten Projekt zugegriffen werden können, oder auf spezifische Projekte (/job/<project-name>/configure) beschränkt sein und daher nur aus dem spezifischen Projekt zugänglich sein.
Laut der Dokumentation: Anmeldeinformationen, die im Scope sind, werden ohne Einschränkung im Pipeline verfügbar gemacht. Um versehentliche Offenlegung im Build-Protokoll zu verhindern, werden Anmeldeinformationen aus der regulären Ausgabe maskiert, sodass ein Aufruf von env (Linux) oder set (Windows) oder Programme, die ihre Umgebung oder Parameter ausgeben, sie nicht im Build-Protokoll offenbaren würden, für Benutzer, die anderweitig keinen Zugriff auf die Anmeldeinformationen haben.
Deshalb muss ein Angreifer beispielsweise die Anmeldeinformationen base64-codieren, um sie abzuschöpfen.
Referenzen
Last updated
