Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- de:modul:ffit:3-jahr:cicd:learningunits:lu12:a [2026/05/14 16:03] – apeter
+++ de:modul:ffit:3-jahr:cicd:learningunits:lu12:a [2026/05/18 23:27] (aktuell) – apeter
@@ Zeile 1: / Zeile 1: @@
-====== LU12a - Placeholder ======
+====== LU12a - Jenkins Secrets ======
+Lokal werden Secrets oft in privaten ''.env''-Dateien gespeichert. Bei Build-Pipelines müssen die Secrets auf dem Build-Server (oder einem 3rd-Party-Service) hinterlegt werden. Secrets direkt in die Jenkinsfile-Datei zu schreiben ist keine gute Idee, da sie für alle mit Lesezugriff auf das Code-Repository lesbar wären.
-  * Aktueller Stand
+Die verschiedenen Typen von "secrets", die JEnkins unterstützt, sind in folgender Tabelle aufgelistet.
-  *
-  * .env-Files
+^ Typ ^ Zweck ^ Beispiele ^ Verwendung in Pipeline ^
-  *
+| Secret text | Einzelner String-Wert | API Keys, Tokens | <code groovy>withCredentials([string(...)])</code> |
-  * Secrets in Github
+| Username/Password | Login-Paare | DB, Docker Registry | <code groovy>withCredentials([usernamePassword(...)])</code> |
-  * Secrets in Jenkins
+| SSH Key | SSH Zugriff | Server Deploy, Git SSH | <code groovy>sshUserPrivateKey</code> |
-  *
+| Secret file | Datei als Secret | kubeconfig, JSON Keys, Zertifikate | <code groovy>file(credentialsId, ...)</code> |
-  * Sonar-Token
+| Certificate | X.509 Zertifikate | mTLS, interne APIs | Zertifikatsbasierte Auth (zum Beispiel für Webhooks) |
+Nachfolgend ist die Verwendung in einem Jenkinsfile zu sehen. Die separate Helper-Function sorgt dafür, dass bei mehreren Stages nicht die Secret-ID mehrfach angegeben werden muss.
+^ Jenkinsfile mit Passwort-Leak ❌ ^ Jenkinsfile mit Secret-Helper-Function ✔️ ^
+| <WRAP>
+<code groovy>
+    environment {
+        DB_USER            = "appuser"
+        DB_PASSWORD        = "apppassword"
+    }
+    ...
+            steps {
+                sh """
+                    docker run -d \
+                        --name $DB_CONTAINER \
+                        --restart unless-stopped \
+                        --network infra-net \
+                        -e POSTGRES_USER=$DB_USER \
+                        -e POSTGRES_PASSWORD=$DB_PASSWORD \
+                        -e POSTGRES_DB=$DB_NAME \
+                        -v $DB_VOLUME:/var/lib/postgresql/data \
+                        -v $WORKSPACE/database:/docker-entrypoint-initdb.d \
+                        postgres:17
+                """
+            }
+</code>
+</WRAP> | <WRAP>
+<code groovy>
+def withDbCredentials(body) {
+    withCredentials([
+        usernamePassword(
+            credentialsId: 'postgres-creds',
+            usernameVariable: 'DB_USER',
+            passwordVariable: 'DB_PASSWORD'
+        )
+    ]) {
+        body()
+    }
+}
+...
+            steps {
+                withDbCredentials {
+                    sh """
+                        docker run -d \
+                            --name $DB_CONTAINER \
+                            --restart unless-stopped \
+                            --network infra-net \
+                            -e POSTGRES_USER=$DB_USER \
+                            -e POSTGRES_PASSWORD=$DB_PASSWORD \
+                            -e POSTGRES_DB=$DB_NAME \
+                            -v $DB_VOLUME:/var/lib/postgresql/data \
+                            -v $WORKSPACE/database:/docker-entrypoint-initdb.d \
+                            postgres:17
+                    """
+                }
+            }
+</code>
+</WRAP> |
+Ein wichtiger Grundsatz bezüglich der Sicherheit von Jenkins-Secrets lautet: "Wenn ein Benutzer eine Pipeline editieren kann, kann er in der Regel auch Secrets exfiltrieren."
-''TODO''