Proxy-Zugangsdaten sicher in CI/CD speichern und übertragen: Schritt-für-Schritt-Anleitung

Proxy-Zugangsdaten landen häufiger in öffentlichen Build-Logs, als man denkt. Ein unachtsames curl -v, eine Variable im Klartext, ein Passwort in der URL — schon liegen Ihr Login und Ihr Passwort in der Pipeline-Historie, die das ganze Team sehen kann. In diesem Leitfaden zeigen wir, wie Sie das verhindern.

Einführung: Wie Proxy-Zugangsdaten in Logs und Verlauf gelangen

Stellen Sie sich eine typische Situation vor. Sie konfigurieren einen Build, der über den Proxeon-Proxy auf externe Ressourcen zugreift. Um die Verbindung schnell zu testen, schreiben Sie den Befehl mit dem Passwort direkt in die Adresse: http://user:pass@host:port. Der Build läuft durch, Sie freuen sich. Eine Woche später stellen Sie fest, dass das Passwort im Log jedes Laufs, in der Shell-Historie auf dem Runner und sogar in der Debug-Ausgabe des Clients sichtbar ist.

Das ist keine Seltenheit, sondern die Regel. Proxy-Zugangsdaten haben die unangenehme Eigenschaft, dass sie fast in jedem Netzwerkaufruf benötigt werden und daher leicht an Dutzenden Stellen gleichzeitig durchsickern.

Was Sie am Ende erreichen

Nach diesem Leitfaden können Sie Ihre CI/CD so einrichten, dass Proxy-Zugangsdaten weder in Logs, noch in der Befehls-Historie, noch im Repository auftauchen. Sie lernen, Geheimnisse gängiger Systeme zu nutzen, gefährliche Debug-Modi zu deaktivieren, das Passwort ohne Build-Unterbrechung sicher zu wechseln und alles mit einem fertigen Skript zu überprüfen.

Für wen dieser Leitfaden ist

Das Material richtet sich an Ingenieure auf mittlerem Niveau: DevOps, Backend-Entwickler, QA-Automatisierung. Wenn Sie bereits Pipelines starten und wissen, was eine Umgebungsvariable ist, werden Sie sich wohlfühlen. Fortgeschrittene Leser finden Abschnitte zu Rotation und Audit.

Was Sie bereits wissen sollten

Die grundlegende Einrichtung der Variablen http_proxy und no_proxy erklären wir hier nicht — dafür gibt es separates Material. Es wird angenommen, dass die Verbindung zum Proxy bereits funktioniert und es nun darum geht, die Speicherung der Zugangsdaten sicher zu machen.

Wie viel Zeit Sie benötigen

Zum Lesen und Verstehen benötigen Sie etwa 40 Minuten. Für die Implementierung in eine einzelne Pipeline sollten Sie 30 Minuten bis anderthalb Stunden einplanen, je nach CI-System. Rotation und Leckprüfung fügen Sie später hinzu; sie dauern jeweils 15–20 Minuten.

Vorbereitung: Was Sie brauchen

Bevor Sie beginnen, sammeln Sie alles Notwendige. Das spart Zeit und verhindert Unterbrechungen mitten in der Arbeit.

Werkzeuge und Zugänge

• Zugang zu Ihrem CI/CD-Projekt mit Rechten zum Bearbeiten von Einstellungen und Geheimnissen.
• Ein aktives Proxeon-Proxy-Abonnement mit Login, Passwort, Host und Port.
• Ein lokales System mit installiertem curl, git sowie Python 3 und Node.js, falls Sie die Beispiele ausprobieren möchten.
• Einen Texteditor zum Bearbeiten der Pipeline-Konfiguration.

Systemanforderungen

Es gibt keine besonderen Anforderungen. Alles funktioniert unter Linux, macOS und Windows. CI-Runner basieren normalerweise auf Linux, daher sind die meisten Beispiele in Bash-Syntax gehalten. Abweichungen für Windows-Runner erwähnen wir separat.

Was Sie im Voraus vorbereiten sollten

Notieren Sie Ihre aktuellen Proxy-Zugangsdaten in einem zuverlässigen Passwort-Manager. Sie werden sie für die Einrichtung der Geheimnisse benötigen. Speichern Sie sie nicht in einer einfachen Textdatei auf Ihrem Desktop.

Tipp: Legen Sie ein separates Proxy-Konto für CI an, falls Ihr Proxeon-Tarif dies erlaubt. Dann betrifft ein Leck der Build-Zugangsdaten nicht Ihre persönlichen Zugangsdaten und umgekehrt.

Sicherung der Konfiguration

Bevor Sie die Pipeline ändern, erstellen Sie eine Kopie der aktuellen Konfigurationsdatei. Kopieren Sie einfach .gitlab-ci.yml, die Workflow-Datei oder das Jenkinsfile in einen separaten Ordner außerhalb des Repositorys.

⚠️ Achtung: Legen Sie niemals eine Sicherung an, indem Sie sie in dasselbe Repository committen, insbesondere nicht mit dem Passwort darin. Selbst in einem temporären Branch landen die Zugangsdaten dauerhaft in der Git-Historie.

Grundbegriffe: Einfach erklärt

Wir erklären die wichtigsten Begriffe, damit später keine Verwirrung entsteht.

Proxy-Zugangsdaten

Das sind Login und Passwort, mit denen Ihr Client die Berechtigung zur Nutzung des Proxeon-Proxys nachweist. Manchmal wird statt Login-Passwort eine IP-Bindung verwendet, aber hier sprechen wir über das Paar Login-Passwort.

Geheimnis in CI

Ein Geheimnis ist ein spezieller Speicher in Ihrer CI-System, in den Sie sensible Werte ablegen. Das System verschlüsselt sie und stellt sie Builds als Umgebungsvariable bereit, wobei es sie automatisch in Logs verbirgt.

Maskierung

Bei der Maskierung ersetzt CI den Wert eines Geheimnisses in der Ausgabe durch Sternchen. Wenn das Passwort versehentlich ausgegeben wird, sehen Sie stattdessen etwas wie [MASKED]. Das funktioniert nicht immer perfekt, daher kombinieren wir mehrere Schutzmaßnahmen.

Proxy-Authorization-Header

Wenn sich Ihr Client beim Proxy authentifiziert, sendet er den HTTP-Header Proxy-Authorization mit den kodierten Zugangsdaten. Im ausführlichen Debug-Modus drucken viele Clients diesen Header vollständig aus. Das Dekodieren ist trivial, daher gilt diese Ausgabe als Leck.

Geltungsbereich

Der Geltungsbereich bestimmt, welche Builds auf das Geheimnis zugreifen können. Ein korrekt eingeschränktes Geheimnis ist nur für geschützte Branches sichtbar und gelangt nicht in Forks oder externe Pull-Requests.

Tipp: Merken Sie sich das Grundprinzip: Ein Geheimnis sollte nur so lange im Speicher des Prozesses existieren, wie nötig, und nirgendwo Spuren auf der Festplatte oder in der Ausgabe hinterlassen.

Schritt 1: Die Hauptfalle verstehen — Passwort in der URL

Ziel dieser Stufe: die häufigste Leckquelle erkennen und dauerhaft darauf verzichten.

Der häufigste Fehler: Zugangsdaten direkt in die Proxy-Adresse schreiben: http://user:pass@host:port. Das ist bequem, daher machen es fast alle Anfänger. Das Problem: Solche URLs tauchen an unerwarteten Stellen auf.

Wo genau das Passwort aus der URL auftaucht

1. Prozessliste. Der Befehl ps auf dem Runner zeigt die vollständige Befehlszeile, einschließlich Passwort. Jeder Prozess auf derselben Maschine kann sie lesen.
2. Proxy-Logs selbst. Einige Server-Logs protokollieren die Verbindungszeichenfolge. Wenn die URL ein Passwort enthält, landet es im Log.
3. Shell-Befehlshistorie. Die Datei .bash_history speichert alles, was Sie eingeben, einschließlich des Passworts in der URL.
4. Debug-Ausgabe des Clients. Bei Ausführung mit ausführlichem Modus druckt der Client die Zieladresse zusammen mit den Zugangsdaten.
5. CI-Logs. Wenn die Variable mit der URL nicht als Geheimnis markiert ist, wird sie bei echo oder bei einem Fehler im Klartext ausgegeben.

Überprüfen Sie es jetzt. Führen Sie auf einer beliebigen Maschine einen harmlosen Befehl aus und schauen Sie in die Prozessliste.

curl -x http://myuser:mypass@proxy.proxeon.net:8080 https://example.com & ps aux | grep curl

Sie sehen Ihr Passwort in Klartext in der Ausgabe von ps. Genau das Leck beheben wir.

⚠️ Achtung: Selbst wenn der Build privat ist, kann auf die Prozessliste des Runners ein anderer Prozess, ein anderer Job auf einem gemeinsamen Runner oder ein Überwachungstool zugreifen. Betrachten Sie ein Passwort in der URL als öffentlich.

Erwartetes Ergebnis: Sie kennen die fünf Leckstellen und werden nie wieder das Passwort in die Proxy-Adresse schreiben.

✅ Überprüfung: Führen Sie den obigen Testbefehl aus und stellen Sie sicher, dass Sie das Passwort in der ps-Ausgabe sehen. Wenn ja, haben Sie das Problem korrekt reproduziert und sind bereit, es zu lösen.

Schritt 2: Der richtige Ansatz — Umgebungsvariablen und Credential-Dateien

Ziel dieser Stufe: Zugangsdaten aus der URL in sichere Speicher verlagern — Umgebungsvariablen und spezielle Dateien.

Die Idee ist einfach. Login und Passwort getrennt von der Adresse speichern. Der Client liest sie aus der Umgebung oder aus einer Datei mit eingeschränkten Rechten, nicht aus der Befehlszeile. So landen sie nicht in der Prozessliste oder Historie.

Variante A: Umgebungsvariablen

Viele Clients können Proxy-Zugangsdaten aus der Umgebung lesen. Wir zeigen Beispiele.

curl mit Umgebungsvariable

Setzen Sie die Proxy-Adresse ohne Zugangsdaten und übergeben Sie Login und Passwort als separates Flag, dessen Wert aus einer Variablen stammt.

1. Exportieren Sie eine Variable mit den Zugangsdaten (in CI macht das ein Geheimnis, lokal eine sichere Quelle).
2. Übergeben Sie den Wert über das Flag -U, nicht in der URL.

export PROXY_CREDS="$PROXEON_USER:$PROXEON_PASS"; curl -x http://proxy.proxeon.net:8080 -U "$PROXY_CREDS" https://example.com

Auch das Flag -U mit einer Variablen ist besser als ein Passwort in der URL, aber es ist in ps sichtbar. Daher ist die Credential-Datei unten vorzuziehen.

Python requests

In Python lesen Sie die Zugangsdaten über os.environ aus der Umgebung und bauen das Proxy-Wörterbuch im Speicher auf. Geben Sie nichts aus.

import os, requests; user=os.environ['PROXEON_USER']; pwd=os.environ['PROXEON_PASS']; proxy=f'http://{user}:{pwd}@proxy.proxeon.net:8080'; r=requests.get('https://example.com', proxies={'http':proxy,'https':proxy}); print(r.status_code)

Hier bleibt das Passwort in einer Variable innerhalb des Python-Prozesses und gelangt nicht in die Befehlszeile. Wichtig: Loggen Sie niemals die Variable proxy vollständig.

Node.js

In Node nehmen Sie die Zugangsdaten ebenfalls aus process.env und erstellen den Proxy-Agenten im Code.

const user=process.env.PROXEON_USER; const pass=process.env.PROXEON_PASS; const proxyUrl=`http://${user}:${pass}@proxy.proxeon.net:8080`; const {HttpsProxyAgent}=require('https-proxy-agent'); const agent=new HttpsProxyAgent(proxyUrl); fetch('https://example.com',{agent}).then(r=>console.log(r.status));

Tipp: Loggen Sie in jeder Sprache nur den Antwortstatus und bei Bedarf den Zielhost. Geben Sie niemals das gesamte Proxy-Objekt aus — es enthält das Passwort.

Variante B: .netrc-Datei

Die Datei .netrc ist eine klassische Methode, Zugangsdaten getrennt von Befehlen zu speichern. curl kann sie automatisch lesen.

1. Erstellen Sie die Datei .netrc im Home-Verzeichnis des Runners zur Laufzeit aus dem CI-Geheimnis.
2. Schreiben Sie eine Zeile mit Maschine, Login und Passwort.
3. Setzen Sie die Dateirechte auf 600, damit nur der Besitzer sie lesen kann.
4. Führen Sie curl mit dem netrc-Flag aus.

printf 'machine proxy.proxeon.net login %s password %s' "$PROXEON_USER" "$PROXEON_PASS" > ~/.netrc; chmod 600 ~/.netrc; curl --netrc -x http://proxy.proxeon.net:8080 https://example.com

Jetzt erscheint das Passwort weder in der Befehlszeile noch in der Prozessliste. Es liegt in einer Datei mit Rechten 600, die Sie am Ende des Builds löschen.

⚠️ Achtung: Rechte 600 sind Pflicht. Ohne sie kann curl sich weigern, die Datei zu lesen, und die Datei wird für andere Benutzer auf der Maschine zugänglich.

Variante C: curl-Konfigurationsdatei

curl kann Flags aus einer Konfigurationsdatei lesen. Legen Sie dort Proxy und Zugangsdaten ab und setzen Sie die Rechte auf 600.

printf 'proxy = http://proxy.proxeon.net:8080\nproxy-user = "%s:%s"\n' "$PROXEON_USER" "$PROXEON_PASS" > ~/.curlrc; chmod 600 ~/.curlrc; curl https://example.com

Mit einer .curlrc mit Rechten 600 sind Zugangsdaten weder in der Prozessliste noch in der Historie sichtbar.

Variante D: Anwendungskonfiguration

Wenn Sie eine eigene Anwendung haben, die eine Konfigurationsdatei liest, speichern Sie die Proxy-Zugangsdaten in einer Konfigurationsdatei außerhalb des Repositorys. Im Repository halten Sie nur eine Vorlage mit Platzhaltern, die auf dem Runner mit Werten aus Geheimnissen befüllt wird.

Erwartetes Ergebnis: In keinem Beispiel erscheint das Passwort in der Befehlszeile oder Prozessliste. Es lebt entweder in einer Variable innerhalb des Prozesses oder in einer Datei mit Rechten 600.

✅ Überprüfung: Führen Sie ein Beispiel aus und führen Sie parallel ps aux | grep curl aus. Das Passwort darf nicht in der Ausgabe erscheinen. Falls Sie netrc verwenden, prüfen Sie die Rechte mit ls -l ~/.netrc — es sollte -rw------- sein.

Schritt 3: Geheimnisse in gängigen CI-Systemen — GitHub Actions, GitLab CI, Jenkins

Ziel dieser Stufe: Proxy-Zugangsdaten im geschützten Speicher Ihres CI-Systems ablegen und ohne Lecks einfügen.

GitHub Actions

In GitHub werden Geheimnisse auf Repository- oder Organisationsebene gespeichert.

1. Öffnen Sie das Repository und gehen Sie zu den Einstellungen (Settings).
2. Links finden Sie den Punkt Secrets and variables, dann Actions.
3. Klicken Sie auf New repository secret.
4. Geben Sie einen Namen ein, z. B. PROXEON_USER, und den Wert — Ihren Login. Speichern Sie.
5. Wiederholen Sie den Vorgang für PROXEON_PASS mit dem Passwort.

Im Workflow greifen Sie über den secrets-Kontext auf die Geheimnisse zu und übergeben sie als Umgebungsvariablen an den Schritt.

steps: - name: request env: PROXEON_USER: ${{ secrets.PROXEON_USER }} PROXEON_PASS: ${{ secrets.PROXEON_PASS }} run: printf 'machine proxy.proxeon.net login %s password %s' "$PROXEON_USER" "$PROXEON_PASS" > ~/.netrc; chmod 600 ~/.netrc; curl --netrc -x http://proxy.proxeon.net:8080 https://example.com

GitHub maskiert die Werte der Geheimnisse automatisch in Logs. Falls das Passwort versehentlich ausgegeben wird, sehen Sie drei Sternchen.

⚠️ Achtung: Geheimnisse sind standardmäßig nicht in Workflows verfügbar, die aus Forks über pull_request ausgelöst werden. Ändern Sie dieses Verhalten nicht auf pull_request_target, es sei denn, es ist unbedingt erforderlich — sonst kann ein externer Mitwirkender Ihre Zugangsdaten erhalten.

GitLab CI

In GitLab heißen Geheimnisse CI/CD-Variablen und werden im Projekt konfiguriert.

1. Öffnen Sie das Projekt, gehen Sie zu Settings, dann CI/CD.
2. Klappen Sie den Abschnitt Variables auf und klicken Sie auf Add variable.
3. Geben Sie den Schlüssel PROXEON_USER und den Wert ein.
4. Aktivieren Sie das Kontrollkästchen Masked, damit der Wert in Logs verborgen wird.
5. Aktivieren Sie das Kontrollkästchen Protected, damit die Variable nur für geschützte Branches und Tags verfügbar ist.
6. Wiederholen Sie den Vorgang für PROXEON_PASS.

In .gitlab-ci.yml sind die Variablen automatisch als Umgebung verfügbar.

request: script: - printf 'machine proxy.proxeon.net login %s password %s' "$PROXEON_USER" "$PROXEON_PASS" > ~/.netrc - chmod 600 ~/.netrc - curl --netrc -x http://proxy.proxeon.net:8080 https://example.com

Tipp: Das Maskieren in GitLab funktioniert nur für Werte, die bestimmte Regeln erfüllen: Mindestlänge, keine Zeilenumbrüche, base64-kompatibler Zeichensatz. Wenn das Passwort nicht maskiert wird, zeigt GitLab beim Speichern eine Warnung. Ändern Sie in diesem Fall das Passwort so, dass es den Anforderungen entspricht.

Jenkins

In Jenkins werden Zugangsdaten im Bereich Credentials gespeichert und über das Plugin Credentials Binding eingefügt.

1. Öffnen Sie Manage Jenkins, dann Credentials.
2. Wählen Sie den gewünschten Bereich, z. B. System und Global credentials.
3. Klicken Sie auf Add Credentials.
4. Wählen Sie den Typ Username with password.
5. Geben Sie Login und Passwort des Proxys ein und vergeben Sie eine verständliche ID, z. B. proxeon-creds.

Im Jenkinsfile umschließen Sie die Verwendung mit dem Block withCredentials. Jenkins maskiert die Werte in der Konsole.

withCredentials([usernamePassword(credentialsId: 'proxeon-creds', usernameVariable: 'PROXEON_USER', passwordVariable: 'PROXEON_PASS')]) { sh 'printf "machine proxy.proxeon.net login %s password %s" "$PROXEON_USER" "$PROXEON_PASS" > ~/.netrc; chmod 600 ~/.netrc; curl --netrc -x http://proxy.proxeon.net:8080 https://example.com' }

⚠️ Achtung: Jenkins maskiert nur die Werte, die über Credentials Binding bereitgestellt werden. Wenn Sie das Passwort in Groovy zu einem String zusammenbauen und ausgeben, greift die Maskierung nicht. Arbeiten Sie mit Zugangsdaten nur innerhalb des withCredentials-Blocks und nur in sh-Schritten.

Erwartetes Ergebnis: Die Zugangsdaten liegen im geschützten Speicher Ihres CI-Systems, werden als Umgebung in den Build eingefügt und in Logs maskiert.

✅ Überprüfung: Starten Sie einen Build und öffnen Sie das Log. Stellen Sie sicher, dass statt des Passworts Sternchen oder ein Maskierungsmarker sichtbar sind. Versuchen Sie, die Variable absichtlich mit echo auszugeben — das System sollte sie verbergen.

Schritt 4: Logs — Modi deaktivieren, die Proxy-Authorization ausgeben

Ziel dieser Stufe: Ausführliche Ausgaben entfernen, die den Autorisierungsheader offenlegen, und eine sichere Loglevel beibehalten.

Die CI-Maskierung ist kein Allheilmittel. Wenn der Client den Header Proxy-Authorization in base64 ausgibt und das System das ursprüngliche Passwort nicht wörtlich kennt, kann die Maskierung fehlschlagen. Deshalb schalten wir gefährliche Modi an der Quelle ab.

curl

Das Flag -v und insbesondere --trace geben Header aus, einschließlich der Proxy-Autorisierung. Verwenden Sie in CI den stillen Modus.

1. Entfernen Sie -v, --verbose, --trace und --trace-ascii aus den Build-Befehlen.
2. Zur Fehlerkontrolle verwenden Sie -sS: still, aber Fehler werden angezeigt.
3. Falls Sie debuggen müssen, verwenden Sie --trace nur lokal und niemals in CI.

curl -sS --netrc -x http://proxy.proxeon.net:8080 https://example.com -o /dev/null -w '%{http_code}'

So erhalten Sie nur den Antwortstatus ohne einen einzigen Header in der Ausgabe.

Python requests

Die Bibliothek requests gibt Zugangsdaten von sich aus nicht aus, aber aktiviertes urllib3-Logging auf DEBUG-Ebene gibt Request-Header aus. Halten Sie das Loglevel auf WARNING oder INFO.

import logging; logging.getLogger('urllib3').setLevel(logging.WARNING)

Tipp: Wenn Sie für die Diagnose dennoch DEBUG benötigen, fügen Sie einen Log-Filter hinzu, der den Header Proxy-Authorization aus Nachrichten entfernt. Einfacher ist es, lokal zu debuggen und in CI WARNING zu verwenden.

Node.js

In Node vermeiden Sie das Setzen der Umgebungsvariable NODE_DEBUG=http in CI — sie gibt Header aus. Geben Sie auch nicht das gesamte Agent- oder Request-Objekt aus.

1. Entfernen Sie NODE_DEBUG aus der Runner-Umgebung.
2. In Fehlerhandlern geben Sie nur error.message aus, nicht das gesamte Objekt.
3. Verwenden Sie in Produktions-Builds keine HTTP-Request-Logger-Bibliotheken.

⚠️ Achtung: Ein Stacktrace einer unbehandelten Ausnahme kann auch die Proxy-URL mit Zugangsdaten enthalten, wenn Sie die URL mit Passwort aufgebaut haben. Ein weiterer Grund, das Passwort nicht in die URL zu setzen, sondern netrc oder separate Felder zu verwenden.

Erwartetes Ergebnis: Kein Tool gibt in CI den Autorisierungsheader oder die vollständige Proxy-URL aus.

✅ Überprüfung: Führen Sie einen Build aus und suchen Sie im Log nach Proxy-Authorization, Basic und Ihrem Benutzernamen. Es darf keine Übereinstimmung geben.

Schritt 5: Passwortrotation ohne Build-Unterbrechung

Ziel dieser Stufe: Das Passwort so ändern, dass Builds nicht fehlschlagen und das alte Passwort ungültig wird.

Das Proxy-Passwort sollte regelmäßig und unbedingt nach jedem Leckverdacht geändert werden. Die Aufgabe ist, dies ohne Ausfallzeit zu tun.

Überlappungsstrategie

Idealerweise sind eine Zeit lang sowohl altes als auch neues Passwort gültig. Wenn Ihr Proxeon-Tarif ein zweites Konto oder ein zusätzliches Zugangsdaten-Set erlaubt, nutzen Sie das.

1. Erstellen Sie neue Proxy-Zugangsdaten im Proxeon-Kundenportal, ohne alte zu löschen.
2. Fügen Sie die neuen Werte als temporäre Geheimnisse in CI ein, z. B. PROXEON_USER_NEW.
3. Stellen Sie die Pipeline in einem separaten Branch auf die neuen Namen um und führen Sie einen Build aus.
4. Stellen Sie sicher, dass der Build mit den neuen Zugangsdaten erfolgreich ist.
5. Ersetzen Sie die Werte der Hauptgeheimnisse PROXEON_USER und PROXEON_PASS durch die neuen.
6. Entfernen Sie die temporären Geheimnisse.
7. Widerrufen Sie die alten Zugangsdaten im Proxeon-Portal.

So ist zu jedem Zeitpunkt ein funktionierendes Zugangsdaten-Set vorhanden und Builds schlagen nicht fehl.

Wenn keine Überlappung möglich ist

Wenn nur ein einziges Zugangsdaten-Paar verfügbar ist, handeln Sie in einem ruhigen Zeitfenster.

1. Wählen Sie einen Zeitpunkt mit geringer Build-Aktivität.
2. Pausieren Sie den Start neuer Pipelines für ein paar Minuten.
3. Ändern Sie das Passwort im Proxeon-Portal.
4. Aktualisieren Sie sofort den Wert des Geheimnisses in CI.
5. Starten Sie einen Test-Build.
6. Setzen Sie den normalen Betrieb fort.

Tipp: Erstellen Sie eine kurze Rotationsanleitung und bewahren Sie sie neben der Pipeline-Beschreibung auf. In einer Stresssituation nach einem Leck spart eine vorbereitete Schrittliste Nerven und Zeit.

⚠️ Achtung: Nach dem Passwortwechsel löschen Sie unbedingt alte netrc- oder curlrc-Dateien vom Runner, falls sie zwischen Builds zwischengespeichert werden. Sonst verwendet der Client weiterhin die alten Zugangsdaten.

Erwartetes Ergebnis: Das Passwort wurde geändert, neue Builds laufen mit den neuen Zugangsdaten, das alte Passwort funktioniert nicht mehr.

✅ Überprüfung: Versuchen Sie eine Anfrage mit dem alten Passwort — es sollte ein Proxy-Autorisierungsfehler zurückkommen. Der neue Build läuft erfolgreich.

Schritt 6: Leckprüfung — fertiges Audit-Skript

Ziel dieser Stufe: Sicherstellen, dass keine Zugangsdaten in Artefakten, Logs und Repository vorhanden sind, und diese Prüfung automatisieren.

Wo suchen

• Build-Artefakte: erstellte Dateien, Berichte, Dumps.
• Pipeline-Logs, einschließlich alter Läufe.
• Git-Verlauf des Repositorys.
• Caches und temporäre Dateien des Runners.

Suche in Artefakten und Logs

Laden Sie Artefakte und Logs in einen lokalen Ordner herunter und suchen Sie nach charakteristischen Markern: Benutzername, Teil des Passworts, Wort Basic und Autorisierungsheader.

grep -RniE 'proxy-authorization|Basic [A-Za-z0-9+/=]{8,}|proxeon.*login|:[^@/]+@proxy' ./artifacts ./logs

Das Skript sucht nach dem Autorisierungsheader, base64-Zeichenfolgen nach dem Wort Basic, dem Login-Muster in netrc und dem Hinweis auf ein Passwort in der URL vor dem @-Zeichen. Jede Übereinstimmung ist ein Grund zur Untersuchung.

Suche in der Git-Historie

Ein Passwort könnte in einem alten Commit gelandet sein. Überprüfen Sie die gesamte Historie.

git log -p -S 'proxy.proxeon.net' --all | grep -nE ':[^@/]+@proxy|password [^ ]+'

⚠️ Achtung: Wenn das Passwort in der Git-Historie gefunden wird, reicht das bloße Löschen der Datei nicht aus — es bleibt in alten Commits. Sie müssen die Historie mit speziellen Werkzeugen umschreiben und, was wichtiger ist, das Passwort sofort ändern. Betrachten Sie dieses Passwort als kompromittiert.

Automatisierung in der Pipeline

Fügen Sie einen separaten Job hinzu, der die erstellten Artefakte vor der Veröffentlichung scannt und bei einem Fund fehlschlägt. So ein Schutz fängt Lecks, bevor sie nach außen gelangen.

leak_check: script: - if grep -RniE 'proxy-authorization|Basic [A-Za-z0-9+/=]{8,}' ./artifacts; then echo 'LEAK DETECTED'; exit 1; fi

Tipp: Zusätzlich können Sie lokale Secret-Scanner in der Pre-Commit-Phase einrichten. Sie fangen Zugangsdaten bereits vor dem Commit ab und verhindern so, dass sie ins Repository gelangen.

Erwartetes Ergebnis: Manuelles Audit und automatischer Job bestätigen, dass keine Zugangsdaten an einer der Stellen vorhanden sind.

✅ Überprüfung: Führen Sie das Audit-Skript aus — es sollte ohne Übereinstimmungen enden. Legen Sie dann absichtlich eine Testzeile mit dem Basic-Marker in ein Artefakt und stellen Sie sicher, dass das Skript sie findet und fehlschlägt.

Schritt 7: Checkliste vor dem Pipeline-Go-Live

Ziel dieser Stufe: Die endgültige Prüfung durchlaufen, bevor die Pipeline in Betrieb geht.

Gehen Sie die Liste durch und haken Sie jeden Punkt ab. Wenn auch nur einer nicht erfüllt ist, veröffentlichen Sie die Pipeline nicht.

1. Das Proxy-Passwort ist nirgendwo in einer URL der Form user:pass@host geschrieben.
2. Login und Passwort werden nur in CI-Geheimnissen, nicht in Repository-Dateien gespeichert.
3. Die Geheimnisse sind als maskierbar und geschützt markiert.
4. Geheimnisse sind für Builds aus Forks und externen Pull-Requests nicht verfügbar.
5. Aus den Befehlen wurden Flags für ausführlichen Modus und Traces entfernt.
6. Das Loglevel der HTTP-Bibliotheken ist nicht DEBUG.
7. Debug-Variablen wie NODE_DEBUG fehlen in der Runner-Umgebung.
8. netrc- und curlrc-Dateien werden zur Laufzeit erstellt und haben die Rechte 600.
9. Credential-Dateien werden am Ende des Builds gelöscht oder liegen auf einem ephemeren Runner.
10. In der Pipeline gibt es einen Job zur Leckprüfung.
11. Die Git-Historie wurde überprüft und enthält keine Zugangsdaten.
12. Es gibt eine Rotationsanleitung für das Passwort.

Tipp: Speichern Sie diese Checkliste als Vorlage und fügen Sie sie jedem neuen Pipeline mit Proxy-Nutzung bei. Einheitlichkeit reduziert Fehler.

✅ Überprüfung: Alle zwölf Punkte sind abgehakt. Erst jetzt ist die Pipeline bereit für den Go-Live.

Ergebnisprüfung: Wie Sie sicherstellen, dass alles funktioniert

Fassen wir die endgültige Prüfung in einem einzigen Szenario zusammen.

Funktions-Checkliste

• Der Build greift erfolgreich über den Proxeon-Proxy auf Ressourcen zu und erhält die erwarteten Antworten.
• Im Build-Log gibt es kein Passwort, keinen Login, keine base64-Autorisierungszeilen und keine vollständige Proxy-URL.
• In der Prozessliste des Runners während der Anfrage ist kein Passwort vorhanden.
• Artefakte sind sauber, das Audit-Skript findet keine Übereinstimmungen.
• Geheimnisse werden auch bei absichtlichem echo maskiert.

So testen Sie

1. Führen Sie die vollständige Pipeline von Anfang bis Ende aus.
2. Öffnen Sie das Log und suchen Sie nach dem Benutzernamen — es darf keine Übereinstimmung geben.
3. Laden Sie Artefakte herunter und führen Sie das Audit-Skript darüber aus.
4. Prüfen Sie den Leckprüf-Job — er sollte grün sein.

Erfolgskriterien

Erfolg sieht so aus: Der Build ist grün, Anfragen über den Proxy funktionieren, und die Suche an allen möglichen Stellen findet keinen einzigen Fragment der Zugangsdaten. Wenn das zutrifft, haben Sie das Ziel dieses Leitfadens erreicht.

Häufige Fehler und Lösungen

Wir behandeln häufige Probleme nach dem Schema: Problem, Ursache, Lösung.

Problem 1: Passwort immer noch im Log sichtbar

Ursache: Die Variable wurde als normale Variable statt als Geheimnis erstellt oder nicht als maskierbar markiert.

Lösung: Verschieben Sie den Wert in den Geheimnis-Bereich, aktivieren Sie die Maskierung und prüfen Sie, ob der Variablenname in Konfiguration und Speicher übereinstimmt.

Problem 2: Maskierung in GitLab funktioniert nicht

Ursache: Das Passwort enthält Zeichen oder Zeilenumbrüche, die für die Maskierung unzulässig sind.

Lösung: Ändern Sie das Passwort in eine Zeichenfolge aus Buchstaben, Ziffern und zulässigen Zeichen mit ausreichender Länge, die den Maskierungsregeln entspricht.

Problem 3: curl liest netrc nicht

Ursache: Die Dateirechte sind falsch oder die Datei liegt nicht im Home-Verzeichnis.

Lösung: Setzen Sie die Rechte mit chmod auf 600 und stellen Sie sicher, dass der Pfad zur Datei erwartet wird, oder geben Sie den Pfad mit dem Flag --netrc-file an.

Problem 4: Passwort im Stacktrace bei Fehlern

Ursache: Die Proxy-URL wurde mit Zugangsdaten aufgebaut, und der Client gibt sie in der Ausnahme aus.

Lösung: Verwenden Sie netrc oder separate Felder für Login und Passwort, damit die URL keine Zugangsdaten enthält, und geben Sie nur die Fehlermeldung aus.

Problem 5: Altes Passwort wird nach Rotation weiterhin verwendet

Ursache: Eine zwischengespeicherte netrc- oder curlrc-Datei blieb auf dem Runner.

Lösung: Löschen Sie die Zugangsdaten-Dateien am Ende jedes Builds und verwenden Sie ephemere Runner, bei denen das Dateisystem zwischen Läufen bereinigt wird.

Problem 6: Geheimnis in Fork-Pull-Request durchgesickert

Ursache: Ein Modus ist aktiviert, der externen PRs Zugriff auf Geheimnisse gewährt.

Lösung: Deaktivieren Sie diesen Modus, starten Sie Builds mit Geheimnissen nur für vertrauenswürdige Branches und führen Sie Überprüfungen externer PRs ohne Proxy-Zugriff durch.

Problem 7: Passwort in Git-Historie gefunden

Ursache: Irgendwann wurden Zugangsdaten in eine Konfigurationsdatei committet.

Lösung: Ändern Sie sofort das Passwort, schreiben Sie dann die Repository-Historie um und entfernen Sie sensible Daten aus allen Commits.

Zusätzliche Möglichkeiten: Erweiterter Schutz

Wenn der Basisschutz eingerichtet ist, können Sie ihn verstärken.

Externer Geheimnis-Manager

Statt Zugangsdaten direkt im CI-System zu speichern, binden Sie einen externen Geheimnis-Manager an. Die Pipeline erhält die Zugangsdaten über ein kurzlebiges Token nur für die Dauer des Builds. So liegen Geheimnisse nicht dauerhaft in den Projekteinstellungen.

Kurzlebige Tokens statt Passwort

Wenn die Proxeon-Infrastruktur und Ihr Zugriffsschema dies unterstützen, bevorzugen Sie temporäre Tokens mit begrenzter Lebensdauer. Selbst bei einem Leck wird ein solches Token schnell wertlos.

Getrennte Zugangsdaten für Umgebungen

Verwenden Sie verschiedene Zugangsdaten für Test- und Produktions-Builds. Ein Leck von Test-Zugangsdaten betrifft keine produktiven Prozesse.

Tipp: Richten Sie Benachrichtigungen über anomale Aktivitäten auf dem Proxy-Konto ein. Ein plötzlicher Anstieg von Anfragen oder Verbindungen aus unerwarteten Quellen ist ein Signal für ein mögliches Leck und erfordert sofortige Rotation.

Automatische Rotation

Fortgeschrittene Teams automatisieren die Rotation nach Zeitplan: Ein Skript erstellt neue Zugangsdaten, aktualisiert das Geheimnis und widerruft alte, ohne menschliches Zutun. Beginnen Sie mit einer manuellen Anleitung und fügen Sie die Automatisierung hinzu, wenn der Prozess etabliert ist.

FAQ: Häufige Fragen

Kann ich mich einfach auf die CI-Maskierung verlassen und mir keine Sorgen machen?

Nein. Die Maskierung erfasst nur exakte Übereinstimmungen des bekannten Werts. Einen Header in base64 oder eine Teilausgabe kann sie übersehen. Kombinieren Sie die Maskierung mit dem Verzicht auf Passwörter in URLs und dem Abschalten ausführlicher Logs.

Was ist sicherer: Umgebungsvariable oder netrc-Datei?

Für curl ist die netrc-Datei mit Rechten 600 vorzuziehen, weil der Wert nicht einmal in die Prozessliste gelangt. Für Code in Python und Node sind Umgebungsvariablen, die innerhalb des Prozesses gelesen werden, praktischer. Beide Varianten sind bei sorgfältigem Umgang sicher.

Muss ich die Zugangsdaten-Datei nach dem Build löschen?

Ja, wenn der Runner wiederverwendet wird. Auf ephemeren Runnern, bei denen die Maschine nach dem Build vernichtet wird, ist das weniger kritisch, aber das Löschen am Ende ist in jedem Fall eine gute Gewohnheit.

Was tun, wenn das Proxy-Passwort Sonderzeichen enthält?

In netrc und in separaten Feldern sind Sonderzeichen meist kein Problem. Probleme entstehen gerade bei der Eingabe in URLs, wo Zeichen wie @ und : die Analyse stören. Ein weiteres Argument, das Passwort nicht in die URL zu setzen.

Gibt requests Zugangsdaten von sich aus aus?

Standardmäßig nein. Ein Leck entsteht durch aktiviertes DEBUG-Logging von urllib3 oder durch das Ausgeben des Proxy-Einstellungsobjekts. Halten Sie das Logging auf WARNING und geben Sie keine Einstellungen vollständig aus.

Ist das Passwort in der Prozessliste sichtbar, wenn ich das Flag --proxy-user verwende?

Ja, ein Flag in der Befehlszeile ist in ps sichtbar. Verwenden Sie für curl daher netrc oder curlrc, wo die Zugangsdaten nicht als Argument übergeben werden.

Wie oft sollte ich das Proxy-Passwort ändern?

Eine planmäßige Rotation, z. B. quartalsweise, ist sinnvoll, und unbedingt sofort bei jedem Leckverdacht. Die Rotationsanleitung aus Schritt 5 hilft, das schnell zu tun.

Kann ich Zugangsdaten in einer verschlüsselten Datei im Repository speichern?

Technisch ja, aber das verkompliziert den Prozess und birgt das Risiko eines Schlüssellecks. CI-Geheimnisse und externe Geheimnis-Manager lösen das Problem einfacher und sicherer. Erfinden Sie Ihr eigenes Speicherformat nur, wenn es unbedingt nötig ist.

Was tun, wenn bereits ein Leck aufgetreten ist?

Handeln Sie der Reihe nach: Ändern Sie sofort das Proxy-Passwort, widerrufen Sie alte Zugangsdaten, finden Sie alle Leckstellen mit dem Audit-Skript, schreiben Sie bei Bedarf die Git-Historie um, und analysieren Sie die Ursache, damit es nicht wieder passiert.

Gelten diese Empfehlungen auch für Windows-Runner?

Ja, die Prinzipien sind dieselben. Unterschiedlich ist die Syntax: Statt export verwenden Sie die für Ihre Shell passende Methode zum Setzen von Variablen, und statt chmod konfigurieren Sie die Dateirechte über die Dateieigenschaften. Die Logik der Speicherung und des Abschaltens von Logs ist identisch.

Fazit

Sie haben den Weg von der unsicheren Gewohnheit, das Passwort in die URL zu schreiben, bis hin zum vollständigen Schutz der Proxy-Zugangsdaten in CI/CD gemeistert. Erinnern wir uns, was Sie erreicht haben.

Sie haben gelernt, fünf Leckstellen zu erkennen und auf das Passwort in der Proxy-Adresse zu verzichten. Sie haben Zugangsdaten in Umgebungsvariablen und Dateien wie netrc, curlrc und Client-Konfigurationen mit Rechten 600 verlagert. Sie haben Geheimnisse in GitHub Actions, GitLab CI und Jenkins mit Maskierung und eingeschränktem Geltungsbereich eingerichtet. Sie haben ausführliche Logs abgeschaltet, die den Autorisierungsheader ausgeben, bei curl, Python requests und Node. Sie haben die Passwortrotation ohne Build-Unterbrechung gemeistert und ein fertiges Audit-Skript zur Leckerkennung erstellt. Schließlich haben Sie die finale Checkliste vor dem Go-Live durchlaufen.

Was Sie als Nächstes tun sollten. Führen Sie die Checkliste als verbindlichen Review-Schritt für alle Pipelines ein, die den Proxeon-Proxy nutzen. Fügen Sie den Leckprüf-Job allen Projekten hinzu. Wechseln Sie schrittweise zu einem externen Geheimnis-Manager und kurzlebigen Tokens, sobald der Basisprozess zur Gewohnheit wird.

Wie Sie sich weiterentwickeln können. Studieren Sie Praktiken für Geheimnisverwaltung im Unternehmensmaßstab, automatische Rotation und Überwachung von Anomalien auf dem Proxy-Konto. Die Sicherheit von Zugangsdaten ist keine einmalige Einrichtung, sondern eine kontinuierliche technische Disziplin. Aber jetzt haben Sie eine solide Basis, auf der Sie alles Weitere aufbauen können. Viel Erfolg bei sicheren Builds.