80. pepsi-helper-token-refresh

Erneuert OAuth-Access-Tokens für die Smarthost-Relay-Stage.

80.1. Rolle

Ein mit AUTH = oauth konfigurierter Smarthost-MTA (siehe pepsi-stage-relay-to-smarthost) authentifiziert sich mit einem SASL-Bearer-Token, das die Relay-Stage bei jeder Zustellung frisch aus einer TOKEN_FILE liest. Diese Access-Tokens sind kurzlebig, sodass die Datei außerhalb des Bandes erneuert werden muss.

pepsi-helper-token-refresh tut das: Für jeden [pepsi-stage-relay-to-smarthost-mta-<name>] mit AUTH = oauth paart es die TOKEN_FILE/USERNAME des MTA mit einem Geheimnis-Abschnitt [pepsi-helper-token-refresh-<name>] (den OAuth-Client-Zugangsdaten, in einer separaten @inline-secret@-Datei gehalten, die nur für diesen Dienst lesbar ist), fordert ein frisches Token vom TOKEN_ENDPOINT des Anbieters an und schreibt es atomar in die Token-Datei. GRANT wählt den RFC-6749-Grant aus: refresh_token (der Standardwert, z. B. Google; erfordert zusätzlich REFRESH_TOKEN) oder client_credentials (z. B. Microsoft 365 app-only; erfordert SCOPE); CLIENT_ID und CLIENT_SECRET sind in beiden Fällen erforderlich. Ein rotiertes Refresh-Token wird im privaten [pepsi-helper-token-refresh] STATE_DIR (Standardwert /var/pepsi/token-refresh) dauerhaft gespeichert. Ein Ziel, dessen Geheimnis-Abschnitt kein TOKEN_ENDPOINT hat, wird übersprungen, unter der Annahme, dass sein Token auf anderem Wege bereitgestellt wird.

Es ist keine Stage und bewusst nicht Teil von pepsi.target — es ist eine Implementierung des externen Erneuerungsvertrags, der in Die Pipeline erweitern beschrieben ist, und ein Standort kann seine eigene einsetzen. Referenz: pepsi-helper-token-refresh(1).

80.2. Sicherheit

Der Dienst läuft als das dedizierte pepsi-helper-token-refresh-Konto, der einzige Leser der Client-Geheimnisse. Er schreibt Token-Dateien in ein Verzeichnis, das SGID auf die pepsi-token-Gruppe ist (Standardwert /var/pepsi/tokens), Modus 0640; das Relay-Stage-Binärprogramm wird SGID pepsi-token installiert, damit der pepsi-Worker des Dispatchers sie lesen kann. Siehe Die Pipeline erweitern für den vollständigen Vertrag.

80.3. Modi

  • service (der Standardwert) — ein langlebiger Prozess, der jedes Token proaktiv erneuert, um REFRESH_MARGIN (Standardwert 5 min) vor dem Ablauf, und ein fehlschlagendes Ziel mit Backoff wiederholt, während er sein vorheriges Token an Ort und Stelle belässt. Läuft bis SIGINT/SIGTERM.

  • –once — jedes Ziel einmalig erneuern und sich beenden (ein manueller Lauf, ein systemd-Timer oder Cron); Exit-Status ungleich null, wenn irgendein Ziel fehlschlug.

80.4. Siehe auch

pepsi-stage-relay-to-smarthost, pepsi-setup, pepsi-helper-token-refresh(1), pepsi.conf(5).