Im Teamscale-Dogu nimmt der Go-Proxy HTTP-Anfragen auf Port 8080 entgegen.\nDer Proxy leitet an einen separaten Teamscale-Adapter über den Unix-Socket\n/tmp/teamscale-pat/adapter.sock weiter. Teamscale lauscht intern auf 127.0.0.1:8081. Die Setup- und Backup-Aufrufe\nverwenden diesen internen Port. Auch nach dem Wiederherstellen einer alten\nKonfiguration werden Port und Bind-Adresse vor dem Teamscale-Start gesetzt. Der externe Dogu-Nginx und der TCP-Healthcheck\nverwenden weiterhin Port 8080. Die Port- und Bind-Einstellungen stehen in\nconfig/teamscale.properties, siehe Teamscale-Dokumentation.
Für /teamscale/api und /teamscale/api/… gilt:
pat_ sendet der Proxy\neinen GET-Request mit dem ursprünglichen Authorization-Header an\nhttps://<fqdn>/cas/api/pats/validate?scope=/teamscale.\nDen FQDN liest das Startskript mit doguctl config --global fqdn aus.doguctl config -e das Ersatzpasswort unter pat/storedkey/<username> aus.\nFür den Schlüssel wird jedes Zeichen außerhalb von A–Z, a–z, 0–9 und _\ndurch _ ersetzt, beispielsweise alice@example/team durch alice_example_team.\nFehlt der Key, erzeugt und speichert der Adapter ihn über die Teamscale-API.\nDer Benutzername im Authorization-Header bleibt unverändert. Fehler beim erstmaligen Auslesen\noder ein leeres Passwort führen zu HTTP 502 ohne Weiterleitung an Teamscale.Andere Pfade sowie Anfragen ohne Basic Auth oder ohne pat_-Passwort werden ohne\nCAS-Prüfung weitergeleitet. Pfad, Query, Methode und Body bleiben erhalten;\nHTTP-Verbindungsheader werden für die jeweilige Verbindung neu verwaltet.\nDer Proxy protokolliert keine Zugangsdaten und folgt keinen CAS-Redirects.\nValidierungsergebnisse werden nicht gecacht.
Das Startskript übergibt die Konfiguration als CLI-Parameter:
\nfqdn="$(doguctl config --global fqdn)"\n/usr/local/bin/pat-proxy --listenAddress 0.0.0.0:8080 \\\n --upstreamSocket /tmp/teamscale-pat/adapter.sock --apiPath /teamscale/api \\\n --casUrl "https://${fqdn}/cas/api/pats/validate" --scope /teamscale \\\n --validationTimeout 5 --validationEnabled=true --casInsecure=true--casInsecure=true deaktiviert die TLS-Zertifikatsprüfung für die bisherige\nTestinstallation. Mit passendem Zertifikat --casInsecure=false verwenden.\nDer Scope wird vom Proxy an die CAS-URL angehängt.
Das gespeicherte Ersatzpasswort muss von Teamscale für den jeweiligen Benutzer\nakzeptiert werden. Der Prozessbenutzer teamscale benötigt Zugriff auf die\nentsprechenden doguctl-Konfigurationswerte. Die Passwortabfrage wird nicht gecacht.
Proxy, Adapter und Teamscale laufen als Benutzer teamscale. Beim Ende eines der drei\nProzesse werden auch die anderen beendet und der Container beendet sich mit Fehlerstatus.\nSIGTERM/SIGINT werden an alle drei Prozesse weitergegeben.
Die Stage Setup im Jenkinsfile aktiviert pat/enabled in CAS\nüber ecoSystem.setup(registryConfig: ...). Sie erzeugt pro Build gemeinsame\ntechnische API-Zugangsdaten für CAS und Usermgt und übergibt diese über\nregistryConfigEncrypted unter experimental/totp/api_user_name und\nexperimental/totp/api_user_password. Das Setup schreibt die Werte verschlüsselt,\nbevor die Dogus starten. Eine TOTP-Aktivierung ist für diese PAT-Tests nicht nötig;\nUsermgt benötigt für seinen PAT-Endpunkt keinen eigenen pat/enabled-Wert.\nDie API-Zugangsdaten authentifizieren Usermgt gegenüber CAS; der PAT-Eigentümer\nwird weiterhin aus der angemeldeten Testuser-Session bestimmt.
Die provisionierten CAS- und Usermgt-Versionen müssen PAT-Unterstützung enthalten.\nDas Jenkinsfile installiert standardmäßig die veröffentlichten official-Abhängigkeiten;\ndie benachbarten lokalen Repositories werden dadurch nicht automatisch gebaut.
make -C pat-proxy testDie Adapter-Tests verwenden lokale Teamscale-Testserver und simulierte Konfigurationsablagen;\nechte PATs oder ein laufendes CAS sind nicht nötig. Sie prüfen unter anderem Erneuerung,\neinmaligen Retry, Requests mit Body, parallele Erneuerungen und das Logging.
\nDer Proxy schreibt JSON-Logs nach stderr, sichtbar in den Container-Logs:
\ndocker logs -f <containername>\n# Bei Kubernetes:\nkubectl logs -f <podname> -c <containername>Die Anfrageereignisse des Proxys enthalten component: "pat-proxy", requestId, event und\nelapsedMs. Vom Proxy erzeugte Fehlerantworten enthalten dieselbe ID im Header\nX-Pat-Proxy-Request-Id. Es werden keine Benutzernamen, Zugangsdaten,\nRequest-URLs, Bodies oder ungefilterten Fehlermeldungen ausgegeben.
| Ereignis / Code | \nBedeutung | \n
|---|---|
cas_validation_ok | \nCAS hat HTTP 200 geliefert; anschließend wird das Ersatzpasswort ausgelesen | \n
cas_validation_rejected | \nCAS-Status steht in casStatus, der Client-Status in responseStatus | \n
cas_validation_error / CAS_TIMEOUT | \nCAS hat innerhalb von fünf Sekunden keine Antwortheader geliefert | \n
cas_validation_error / CAS_CONNECTION_ERROR | \nVerbindung zu CAS fehlgeschlagen, z. B. wegen DNS, Verbindungsablehnung oder TLS | \n
upstream_connection_error | \nVerbindung zum Teamscale-Adapter über den Unix-Socket fehlgeschlagen; Antwort HTTP 502 | \n
upstream_response | \nDer Adapter hat HTTP 4xx/5xx geliefert (upstreamStatus); die Antwort kann von Teamscale oder vom Adapter stammen | \n
Der Adapter schreibt ebenfalls JSON-Logs nach stderr, mit component: "teamscale-adapter".\nSein Mindestlevel folgt beim Containerstart der Dogu-Einstellung logging/root\n(Standard WARN), über TEAMSCALE_LOGLEVEL und den expliziten Parameter --logLevel.\nDEBUG, INFO, WARN und ERROR sind zulässig. Fehler beim Verbindungsaufbau, Key-Zugriff,\nErneuern oder Retry verwenden ERROR und bleiben auch bei WARN sichtbar. Erfolgreiche\nAbläufe verwenden INFO. Der separate PAT-Proxy übernimmt diese Einstellung derzeit nicht.\nSeine Anfrageereignisse verwenden dieselben Felder, aber eigene Request-IDs. Diese werden\nnicht mit den Proxy-IDs abgeglichen. upstream_connection_error bezeichnet beim Adapter\ndie Verbindung zu Teamscale auf Port 8081; ein fester Fehlercode grenzt die Ursache ein.\nDieses Ereignis beendet den Adapter nicht und kann während des Teamscale-Starts auftreten.\nupstream_response enthält den endgültigen Teamscale-Status ab HTTP 400.\nDie Erneuerung wird durch stored_access_key_rejected, access_key_renewed,\naccess_key_renewal_failed, access_key_retry_failed und access_key_retry_skipped sichtbar.\nDie vollständige Ereignistabelle steht in der\nAdapter-Dokumentation.
Der Go-Proxy liegt im Image unter /usr/local/bin/pat-proxy. Der Docker-Build lädt\ndas durch PAT_PROXY_VERSION bestimmte Release-Archiv und prüft PAT_PROXY_SHA256SUM.\nDer Teamscale-Adapter wird in einer eigenen Docker-Build-Stage aus diesem Repository\nkompiliert. Nach Änderungen das Image neu bauen.
cloudogu/pat-proxy: CAS-PAT-Proxy.pat-proxy/: Go-Teamscale-Adapter, gebaut als /usr/local/bin/teamscale-adapter.pat-proxy/store.go: Konfigurationszugriff über externe doguctl config -e-Aufrufe.pat-proxy/accessor.go: Liest gespeicherte Keys oder erzeugt und speichert sie über die Teamscale-API.pat-proxy/renewal.go: Erneuert abgelehnte Keys und wiederholt wiederholbare Anfragen höchstens einmal.Fehlt der gespeicherte Key (NO_STORED_KEY), liest der Adapter\nconfig_admin_username und config_admin_access_key über doguctl config -e. Anschließend\nerzeugt ein authentifizierter POST an\nhttp://127.0.0.1:8081/teamscale/api/users/<username>/access-key einen Access-Key.\nDie JSON-Antwort wird als Ersatzpasswort gespeichert. Vorhandene Keys werden\nwiederverwendet; Fehler beim erstmaligen Key-Zugriff führen zu HTTP 502.
Lehnt Teamscale einen gespeicherten Key bei einer validierten PAT-Anfrage mit HTTP 401 ab,\nerneuert der Adapter den Key über die Admin-Zugangsdaten und überschreibt den gespeicherten Wert.\nParallele Erstzugriffe und Erneuerungen sind pro Konfigurationsschlüssel innerhalb des\nAdapter-Prozesses synchronisiert. Ein inzwischen erneuerter Key wird wiederverwendet.\nHTTP 403 und Anfragen ohne validierte PAT-Identität lösen keine Erneuerung aus.
\nAnfragen ohne Body werden höchstens einmal mit dem neuen Key wiederholt. Request-Bodies\nwerden nicht gepuffert: Ohne vorhandene GetBody-Funktion bleibt die aktuelle Antwort HTTP 401,\nund der neue Key steht beim nächsten Aufruf bereit. Scheitern Erneuerung oder Speicherung,\nbleibt ebenfalls die ursprüngliche 401-Antwort erhalten. Ein Verbindungsfehler beim Retry liefert 502.
Der Adapter benötigt Go 1.26.8 und das ausführbare doguctl im PATH.\nClassic- und Multinode-Konfiguration sowie Verschlüsselung übernimmt doguctl.\nIn Multinode muss /var/ces/config für lokal gespeicherte Keys persistent eingebunden sein.\nWeitere CLI-Optionen stehen in pat-proxy/README.md.
Der Proxy entfernt eingehende Header mit dem Präfix X-Internal-Auth- bei jeder\nAnfrage. Nach CAS-Erfolg entfernt er den ursprünglichen Authorization-Header und\nsetzt X-Internal-Auth-Method: cas-pat sowie X-Internal-Auth-User mit dem\nBase64-kodierten ursprünglichen Benutzernamen. Base64 dient nur der sicheren\nHeader-Kodierung. Vertrauen entsteht durch den internen Transport, nicht durch\nBase64. Der Adapter entfernt diese Metadaten vor der Weiterleitung an Teamscale.\nDas Socket-Verzeichnis hat Modus 0700, der Socket 0600; Prozesse desselben\nSystembenutzers gehören damit zur Vertrauensgrenze.
Der eigenständige Proxy enthält keine Teamscale-spezifischen Pfade oder CAS-URL.\n--apiPath legt den zu prüfenden Pfad einschließlich Unterpfaden fest\n(Standard /). Bei aktiver Validierung muss --casUrl gesetzt sein.\n--validationEnabled=false deaktiviert die CAS-Prüfung und erzeugt keine\nValidierungsmarkierung. --upstreamSocket legt einen internen Unix-Socket\nfest; alternativ gelten --upstreamHost (Standard 127.0.0.1) und\n--upstreamPort (Standard 8081). Ein Empfänger validierter Identitäten\nmuss über einen vertrauenswürdigen internen Transport erreichbar sein.
Im Teamscale-Dogu setzt das Startskript Pfad, CAS-URL und Socket-Verbindung.\nTEAMSCALE_ADAPTER_SOCKET überschreibt den gemeinsamen Socket-Pfad. Der Go-Adapter\nliest und erzeugt Keys direkt gegen Teamscale auf Port 8081. Der Konfigurationszugriff erfolgt über doguctl-Prozesse; Logs enthalten keine Zugangsdaten.