Best Practices für sicheres Jenkins Credential Management

Jenkins-Jobs benötigen oft produktionsnahe Geheimnisse: Cloud-Tokens, Registry-Passwörter, Deploy-Keys, Signaturzertifikate und API-Anmeldedaten. Wenn diese Geheimnisse in einem Jenkinsfile, Konsolenlog oder Job-Parameter landen, wird Ihr CI/CD-System zu einem direkten Kompromittierungspfad.

Verwenden Sie das Credentials Plugin, halten Sie Geheimnisse eng begrenzt und injizieren Sie sie nur für den Schritt, der sie benötigt.

Die Grundlage: Das Jenkins Credentials Plugin

Das Credentials Plugin ist der Standardmechanismus, den Jenkins zur Speicherung sensibler Daten verwendet. Es bietet ein zentrales, verschlüsseltes Repository für Anmeldedaten und stellt sicher, dass Geheimnisse niemals in Build-Logs, Quellcode oder Konfigurationsdateien offengelegt werden.

Wenn Jenkins Anmeldedaten speichert, verschlüsselt es sie mit Schlüsselmaterial auf dem Jenkins-Controller, einschließlich Dateien unter JENKINS_HOME/secrets. Jeder mit breitem Zugriff auf das Dateisystem des Controllers und die Jenkins-Konfiguration kann potenziell Geheimnisse wiederherstellen, daher müssen Dateisystem- und Administratorzugriff streng kontrolliert werden.

Wichtige Anmeldedatentypen

Das Verständnis der verfügbaren Anmeldedatentypen ist der erste Schritt zu einer sicheren Implementierung. Wählen Sie den Typ, der am genauesten auf das zu speichernde Geheimnis abgestimmt ist:

Secret Text: Wird für generische, kurze Textwerte wie API-Tokens, Zugriffsschlüssel, OAuth-Tokens oder Webhook-Geheimnisse verwendet.
Benutzername und Passwort: Standardpaarung für die Authentifizierung bei Diensten wie Maven-Repositories, privaten Registries (Docker Hub, Artifactory) oder internen Anwendungen.
SSH-Benutzername mit privatem Schlüssel: Unverzichtbar für den Zugriff auf Remote-Agents, das Klonen privater Git-Repositories oder das Ausführen von Befehlen auf Remote-Infrastruktur. Der private Schlüssel kann direkt eingegeben, als Pfad bereitgestellt oder vom Jenkins-Controller verwaltet werden.
Secret File: Wird zum Hochladen ganzer Dateien verwendet, die sensibel sind, wie Keystores, Zertifikate (.pem, .crt) oder Konfigurationsdateien mit Geheimnissen.

Tipp: Verwenden Sie immer den granularsten möglichen Anmeldedatentyp. Wenn Sie beispielsweise nur einen API-Schlüssel benötigen, verwenden Sie Secret Text, anstatt zu versuchen, ihn in ein Benutzername-und-Passwort-Feld zu packen.

Prinzip der geringsten Privilegien: Begrenzung von Anmeldedaten

Der Anmeldedaten-Scope bestimmt, wo sie in der Jenkins-Umgebung zugänglich sind. Die Anwendung des Prinzips der geringsten Privilegien – nur den für den Job notwendigen Zugriff zu gewähren – ist entscheidend.

1. System-Scope

Systemweit begrenzte Anmeldedaten (gespeichert unter Jenkins verwalten > Anmeldedaten verwalten > Jenkins) sind global für alle Jobs, Ordner und Pipelines auf der Jenkins-Instanz verfügbar.

Verwendung: Verwenden Sie den System-Scope nur für Geheimnisse, die für den gesamten Jenkins-Betrieb erforderlich sind, wie Anmeldedaten, die von globalen Konfigurations-Plugins verwendet werden, oder Geheimnisse, die für alle Agent-Verbindungen benötigt werden.
Warnung: Minimieren Sie die Verwendung des System-Scopes. Jeder kompromittierte Job könnte potenziell auf alle global verfügbaren Geheimnisse zugreifen.

2. Ordner-Scope

Ordner-begrenzte Anmeldedaten werden innerhalb eines bestimmten Ordners definiert (erstellt mit dem Folder-Plugin oder über Organisationsordner). Diese Geheimnisse sind nur für Jobs sichtbar und nutzbar, die sich in diesem Ordner und seinen Unterordnern befinden.

Empfehlung: Bevorzugen Sie immer den Ordner-Scope. Dies unterteilt den Zugriff und begrenzt den Schadensradius, falls ein Projekt kompromittiert wird.

Sichere Injektion in deklarative Pipelines

Härten Sie Anmeldedaten nicht in Pipeline-Skripten fest. Umgebungsvariablen sind nur akzeptabel, wenn Jenkins sie für einen engen Block injiziert und bekannte Geheimniswerte in Logs maskiert.

Die sichere Methode zum Zugriff auf Anmeldedaten in einer deklarativen Pipeline ist die Verwendung des integrierten withCredentials-Schritts. Dieser Schritt lädt die angegebene Anmeldedaten in eine begrenzte Umgebungsvariable, die nur während der Ausführung des Blocks verfügbar ist.

Beispiel 1: Injizieren von Secret Text (API-Token)

Dieses Beispiel ruft sicher eine Secret Text-Anmeldedaten (MY_API_TOKEN) ab und weist ihren Wert der internen Variable SECRET_TOKEN zu. Sobald der withCredentials-Block beendet ist, wird SECRET_TOKEN automatisch aus der Umgebung entfernt.

pipeline {
    agent any
    stages {
        stage('Deploy via API') {
            steps {
                script {
                    withCredentials([string(credentialsId: 'MY_API_TOKEN', variable: 'SECRET_TOKEN')]) {
                        sh "echo 'Rufe externe API auf...'"
                        sh '''
                            curl -X POST \
                              -H "Authorization: Bearer $SECRET_TOKEN" \
                              https://api.mycorp.com/deploy
                        '''
                    }
                }
            }
        }
    }
}

Beispiel 2: Injizieren von Benutzername und Passwort

Bei Verwendung von Benutzername-und-Passwort-Anmeldedaten teilt der withCredentials-Schritt das Geheimnis in zwei Variablen auf: eine für den Benutzernamen und eine für das Passwort, typischerweise mit den Suffixen _USR und _PSW (oder benutzerdefinierten Namen).

pipeline {
    agent any
    stages {
        stage('Login zur Registry') {
            steps {
                withCredentials([usernamePassword(credentialsId: 'DOCKER_REGISTRY_CRED', usernameVariable: 'DOCKER_USER', passwordVariable: 'DOCKER_PASS')]) {
                    sh '''
                        printf '%s' "$DOCKER_PASS" | docker login \
                          --username "$DOCKER_USER" \
                          --password-stdin my.registry.com
                    '''
                }
            }
        }
    }
}

Sicherheitswarnung: Log-Unterdrückung

Jenkins versucht, bekannte Anmeldedatenwerte in Build-Logs zu maskieren, aber Maskierung ist kein Ersatz für sorgfältige Skripte. Drucken Sie keine Geheimnisse, übergeben Sie keine Passwörter in der Befehlszeile und führen Sie keine Shell-Ablaufverfolgung (set -x) in der Nähe der Verwendung von Geheimnissen durch.

Erweiterte Sicherheitsintegration

Für Umgebungen mit hohen Sicherheitsanforderungen reicht es oft nicht aus, sich nur auf den lokalen Jenkins-Masterschlüssel zu verlassen. Die Integration mit einem externen Geheimnisverwaltungssystem bietet Aufgabentrennung, zentrale Überwachung und verbesserte Verschlüsselungsfähigkeiten.

Externe Anmeldedatenspeicher

Beliebte Integrationen umfassen:

HashiCorp Vault: Mit dem Vault-Plugin kann Jenkins zur Laufzeit dynamisch Geheimnisse von Vault anfordern. Das bedeutet, dass die Geheimnisse niemals dauerhaft auf dem Jenkins-Controller gespeichert werden, sondern nur vorübergehend im Speicher während der Ausführungsphase.
AWS Secrets Manager/Azure Key Vault: Cloud-native Plugins ermöglichen es Pipelines, Geheimnisse direkt von diesen Diensten unter Verwendung von IAM-Rollen oder Dienstprinzipalen abzurufen, wodurch die statische Offenlegung von Anmeldedaten minimiert wird.

Die Verwendung externer Speicher entspricht den Sicherheitsbest Practices, indem:

Speicherung getrennt wird: Die Geheimnisinfrastruktur wird vom CI/CD-Server entkoppelt.
Dynamischer Zugriff: Geheimnisse können häufig rotiert werden, ohne dass manuelle Jenkins-Konfigurationsaktualisierungen erforderlich sind.
Verbesserte Überwachung: Alle Zugriffsversuche auf Geheimnisse werden im externen Tresorsystem protokolliert.

Rollenbasierte Zugriffskontrolle (RBAC)

Die Implementierung eines RBAC-Plugins (wie Role-based Authorization Strategy) ermöglicht es Administratoren, nicht nur zu kontrollieren, wer einen Job ausführen kann, sondern auch, wer bestimmte Anmeldedaten konfigurieren und ansehen kann.

Beschränken Sie die Job-Konfigurationsberechtigungen, sodass nur vertrauenswürdige Benutzer Anmeldedaten in Pipelines binden können.
Beschränken Sie die Möglichkeit, Systemweite Anmeldedaten zu ändern oder zu erstellen, auf eine kleine Gruppe von Sicherheits- oder Plattformadministratoren.

Best Practices für das Anmeldedatenmanagement

Praxis	Beschreibung	Sicherheitsvorteil
Ordner-Scope verwenden	Beschränken Sie den Zugriff auf Anmeldedaten auf die spezifischen Jobs/Ordner, die sie benötigen.	Begrenzt die Offenlegung und den Schadensradius.
Hartcodierung vermeiden	Platzieren Sie niemals Geheimnisse in `Jenkinsfile`, Build-Skripten oder der Quellcodeverwaltung.	Beseitigt Schwachstellen im Quellcode.
`withCredentials` verwenden	Injizieren Sie Geheimnisse sicher in Pipeline-Schritte mit der offiziellen Jenkins-API.	Stellt automatische Log-Schwärzung und Umgebungsbereinigung sicher.
Externen Tresor integrieren	Verwenden Sie Vault, AWS Secrets Manager oder Azure Key Vault für Unternehmensbereitstellungen.	Entkoppelt die Speicherung und ermöglicht dynamische Rotation.
RBAC anwenden	Verwenden Sie Autorisierungs-Plugins, um einzuschränken, wer Anmeldedaten konfigurieren, ansehen und verwenden kann.	Setzt das Prinzip der geringsten Privilegien bei Benutzern durch.
Regelmäßige Rotation	Rotieren Sie API-Schlüssel und Passwörter regelmäßig (idealerweise automatisiert über einen externen Tresor).	Minimiert das Zeitfenster für die Ausnutzung kompromittierter Geheimnisse.
Controller sichern	Stellen Sie strenge Dateisystemberechtigungen auf dem Jenkins-Controller sicher, um `master.key` zu schützen.	Schützt den Kernverschlüsselungsmechanismus.

Behandeln Sie Jenkins-Anmeldedaten als Produktionsgeheimnisse. Begrenzen Sie sie eng, binden Sie sie kurz, rotieren Sie sie regelmäßig und halten Sie den Controller-Zugriff auf Personen beschränkt, die berechtigt sind, diese Geheimnisse wiederherzustellen.