Weswegen
Tippen, um zu suchen
    Esc zum Schließen · Sofortsuche auf der ganzen Website

    Jenkins nach dem ersten Benutzer: Sicherheit & Backup

    · Weswegen-Redaktion
    Sonstiges

    Der Setup-Wizard ist durch, der erste Benutzer steht — und jetzt zeigt Jenkins ein leeres Dashboard. Bevor Sie den ersten Job anlegen, lohnen sich ein paar Minuten für Sicherheit, Benutzerverwaltung und Backup. Die wichtigsten Einstellungen, ihre Menüpfade und die häufigsten Fehler der Praxis — der Reihe nach.

    Der erste Benutzer ist bereits Administrator

    Ein verbreitetes Missverständnis vorab: Sie müssen dem ersten Benutzer keine Administrator-Rechte zuweisen. Das Konto, das Sie im Einrichtungsassistenten (dem Schritt nach der Plugin-Installation) anlegen, erhält automatisch volle Rechte. Jenkins aktiviert dabei im Hintergrund gleich mehrere Sicherheitsvoreinstellungen:

    • Security Realm: „Jenkins’ own user database” (Jenkins-eigene Benutzerdatenbank).
    • Autorisierung: „Logged-in users can do anything” (angemeldete Benutzer dürfen alles).
    • Registrierung: Die Selbstregistrierung ist deaktiviert — es kann sich also niemand ohne Ihr Zutun ein Konto anlegen.

    Das ist ein brauchbarer Ausgangspunkt für einen Einzelbenutzer, aber noch nicht das, was Sie für ein Team oder einen öffentlich erreichbaren Server wollen. Die eigentliche Arbeit beginnt jetzt.

    Sicherheit prüfen und verschärfen

    Öffnen Sie Verwalten von Jenkins → Sicherheit (in älteren Versionen: „Configure Global Security”). Drei Dinge sind hier wichtig:

    • Autorisierungsstrategie umstellen. „Logged-in users can do anything” gibt jedem angemeldeten Konto Vollzugriff. Für mehr als eine Person wechseln Sie auf Matrix-based security (Berechtigungen pro Benutzer/Gruppe) oder auf die rollenbasierte Strategie (siehe nächster Abschnitt). Finger weg von „Anyone can do anything” — das schaltet die Anmeldung faktisch ab.
    • CSRF-Schutz aktiv lassen. Der „Crumb Issuer” schützt vor Cross-Site-Request-Forgery und ist seit Jenkins 2.x standardmäßig an. Deaktivieren Sie ihn nicht, auch wenn eine Anleitung im Netz das für ein Plugin vorschlägt.
    • Agent-to-Controller-Zugriffskontrolle ebenfalls aktiviert lassen. Sie verhindert, dass Build-Agenten beliebigen Code auf dem Controller ausführen.

    Benutzer und Rollen sauber trennen

    Sobald mehrere Personen mit Jenkins arbeiten, wird die Matrix-Tabelle schnell unübersichtlich. Sauberer ist das Plugin Role-based Authorization Strategy. Installieren Sie es über Verwalten von Jenkins → Plugins → Verfügbar, dann stellen Sie unter „Sicherheit” die Autorisierung auf „Role-Based Strategy” um.

    Danach erscheint unter Verwalten von Jenkins der Punkt Manage and Assign Roles. Dort definieren Sie:

    • Global roles — etwa admin, developer, viewer mit jeweils passenden Rechten.
    • Project roles — Rollen, die per regulärem Ausdruck nur für bestimmte Jobs gelten (z. B. Pattern frontend-.* für alle Frontend-Pipelines).

    Das Prinzip der minimalen Rechte gilt auch hier: Ein Konto, das nur Builds ansehen soll, braucht keine Konfigurationsrechte. Legen Sie für sich selbst zusätzlich ein separates, unprivilegiertes Konto für den Alltag an und nutzen Sie den Admin-Zugang nur für Verwaltungsaufgaben.

    System und Werkzeuge konfigurieren

    Unter Verwalten von Jenkins → System (früher „Configure System”) setzen Sie die Grundlagen:

    • Jenkins URL korrekt eintragen — sie steckt in Benachrichtigungs-Links und Webhook-Callbacks.
    • System Admin e-mail address hinterlegen, damit Fehler-Mails einen Absender haben.
    • SMTP-Server für E-Mail-Benachrichtigungen konfigurieren (für formatierte Mails zusätzlich das Plugin „Email Extension”).
    • Executors auf dem Controller auf 0 setzen, sobald Sie Build-Agenten nutzen. Der Controller sollte keine Builds selbst ausführen — das ist ein Sicherheits- und Stabilitätsgewinn.

    Die Build-Werkzeuge liegen unter Verwalten von Jenkins → Tools (früher „Global Tool Configuration”): JDK, Git, Maven, Gradle oder NodeJS. Jenkins kann viele davon automatisch herunterladen, oder Sie zeigen auf eine bereits installierte Version auf dem Server.

    Zugangsdaten zentral verwalten

    Passwörter, SSH-Schlüssel und API-Tokens gehören nie im Klartext in eine Pipeline. Das mitgelieferte Credentials-System (unter Verwalten von Jenkins → Credentials) verschlüsselt sie in JENKINS_HOME und stellt sie Jobs über eine ID zur Verfügung. In der Pipeline greifen Sie sie so ab:

    withCredentials([usernamePassword(
    credentialsId: 'git-deploy',
    usernameVariable: 'GIT_USER',
    passwordVariable: 'GIT_PASS')]) {
    sh 'git push https://$GIT_USER:$GIT_PASS@example.com/repo.git'
}

    Da Jenkins fast immer Code aus einem Repository holt, ist ein Deploy-Schlüssel oder Token einer der ersten Einträge, den Sie hier anlegen. Grundlagen dazu finden Sie unter Wie überprüfe ich den aktuellen Git-Status? und Was macht git fetch genau?.

    Plugins gezielt ergänzen — nicht wahllos

    Die im Wizard installierten „empfohlenen Plugins” decken den Einstieg ab. Ergänzen Sie nur, was Sie tatsächlich brauchen — jedes Plugin ist zusätzliche Angriffsfläche und Update-Aufwand. Häufig sinnvoll sind:

    • Configuration as Code (JCasC) — schreibt Ihre komplette Jenkins-Konfiguration in eine versionierbare Datei jenkins.yaml. Ideal, um Einstellungen reproduzierbar und dokumentiert zu halten.
    • Pipeline: Stage View für eine übersichtlichere Darstellung laufender und abgeschlossener Pipelines direkt im klassischen UI. Von Blue Ocean lassen Sie inzwischen besser die Finger: Die aktive Weiterentwicklung wurde eingestellt, das Plugin bekommt keine regelmäßigen Updates mehr und läuft auf aktuellen Jenkins- und Java-Versionen zunehmend unrund.
    • Credentials Binding für den oben gezeigten withCredentials-Block.

    Wichtig: Halten Sie Jenkins und Plugins aktuell. Unter Verwalten von Jenkins → Plugins → Updates und auf der Startseite meldet Jenkins verfügbare Versionen. Für Produktivsysteme empfiehlt sich die LTS-Linie (Long Term Support) statt der wöchentlichen Releases.

    Backup und Wiederherstellung einrichten

    Ihre gesamte Jenkins-Welt — Jobs, Konfiguration, Benutzer, Credentials, Plugins — liegt im Verzeichnis JENKINS_HOME. Wer das sichert, kann Jenkins jederzeit wiederherstellen. Die Standardpfade:

    • Linux (Paketinstallation): /var/lib/jenkins
    • Docker: /var/jenkins_home (als Volume anlegen, sonst ist bei jedem Container-Neustart alles weg)
    • Windows: C:\ProgramData\Jenkins\.jenkins

    Für automatische Sicherungen eignet sich das Plugin ThinBackup, das Konfiguration und Job-Historie regelmäßig wegschreibt —. Verlässlicher ist häufig die Kombination aus rsync/Snapshot des JENKINS_HOME-Verzeichnisses und einer über JCasC versionierten Konfiguration im Git-Repository — dann hängt die Wiederherstellung nicht von einem einzelnen Plugin ab. Wenn Sie einen eigenen Server betreiben, kalkulieren Sie den Speicher dafür ein — Anhaltspunkte gibt Wie viel kostet ein Server im Monat?.

    Typische Fehler nach der Einrichtung

    • Autorisierung offen gelassen. „Logged-in users can do anything” auf einem Team- oder Internet-Server ist ein häufiger Grund für kompromittierte Jenkins-Instanzen.
    • Kein HTTPS. Jenkins lauscht standardmäßig unverschlüsselt auf Port 8080. Setzen Sie einen Reverse-Proxy (nginx, Apache, Caddy) mit TLS davor, statt den Port direkt ins Internet zu öffnen.
    • Jenkins als root betrieben. Nutzen Sie das dedizierte Service-Konto (jenkins), das die Paketinstallation anlegt.
    • Kein Backup. Ein einziges verlorenes JENKINS_HOME kann Wochen an Job-Konfiguration kosten.

    FAQ

    Ist der erste Benutzer automatisch Administrator? Ja. Das im Setup-Wizard angelegte Konto erhält volle Rechte, und die Selbstregistrierung ist deaktiviert. Sie müssen keine Admin-Rechte manuell vergeben — sondern die Berechtigungen für weitere Personen bewusst einschränken.

    Ich habe mich ausgesperrt — wie komme ich wieder rein? Beim ersten Start hat Jenkins ein Initialpasswort in die Datei secrets/initialAdminPassword innerhalb von JENKINS_HOME geschrieben (z. B. /var/lib/jenkins/secrets/initialAdminPassword). Ist der Zugang komplett verloren, lässt sich die Sicherheit über die Konfigurationsdatei config.xml im JENKINS_HOME temporär abschalten und danach neu einrichten.

    Muss ich HTTPS in Jenkins selbst konfigurieren? In der Praxis nicht. Üblich und robuster ist ein vorgelagerter Reverse-Proxy, der die TLS-Verschlüsselung übernimmt und Anfragen intern per HTTP an Jenkins auf Port 8080 weiterreicht.