Extension · moselwal/secret-resolver

secret-resolver — Secrets in Site-Configs, zur Laufzeit.

Schreibt %secret(API_KEY)% direkt in Ihre TYPO3-Site-Configs — wird zur Laufzeit cascading aufgelöst: erst KEY_FILE-Env, dann /run/secrets/, dann Env-Fallback. Erweiterbar über SecretProviderInterface. Container-Deployments brauchen genau das.

Composer-Repo einbinden →
Das Problem

Secrets in Site-Configs sind plain text — oder ungeladen.

Mit secret-resolver

  • %secret(API_KEY)%-Syntax direkt in Site-Config-YAMLs
  • Cascading Lookup: API_KEY_FILE → /run/secrets/api_key → API_KEY Env
  • Out-of-the-box mit Docker und Kubernetes Secrets kompatibel
  • Eigene Provider via SecretProviderInterface (z.B. Vault, AWS SM)
  • Cache-bewusst — keine Re-Lookups bei jedem Request

Bisher

  • API-Keys hardgecodet in YAML-Configs (im Git-Repo)
  • Oder: über ENV-Variablen in TypoScript referenziert (klobig)
  • Docker-/K8s-Secrets via /run/secrets/ nicht out-of-the-box nutzbar
  • Multi-Provider-Lookup (Vault, AWS Secrets Manager) als Custom-Boilerplate

Vier Bausteine

Erweiterbarkeit

SecretProviderInterface implementieren — schon ist Vault, AWS Secrets Manager oder Bitwarden Secrets als zusätzlicher Lookup-Step nutzbar.

Container-tauglich

Funktioniert nahtlos mit Docker Secrets und Kubernetes Mounted Secrets — keine Anpassung am Image-Bau erforderlich.

Cascading Lookup

Default-Reihenfolge: {KEY}_FILE-Env (Pfad), /run/secrets/{key}, dann {KEY}-Env als Fallback. Konfigurierbar pro Provider.

%secret()%-Syntax

Direkt in YAML-Site-Configs einsetzbar — keine Custom-Bootstrap-Logik nötig.

Installation: composer require moselwal/secret-resolver

TYPO3: 14.0+ · PHP: 8.3+

Composer-Repository unter gitlab.moselwal.io einbinden, dann composer require moselwal/secret-resolver. Für saubere Konfigurations-Integration ggf. mit moselwal/typo3-config kombinieren.

Verwendung

Einfache Keys (Cascade-Resolution)

 

# config/sites/main/config.yaml
apiKey: '%secret(API_KEY)%'
dbPassword: '%secret(DB_PASSWORD)%'

# Inline in Strings:
dsn: 'mysql://user:%secret(DB_PASSWORD)%@db:3306/app'

 

Der Key wird durch alle registrierten Provider in Prioritätsreihenfolge aufgelöst — First Match Wins.

Erweiterte Keys (Provider-targeted)

 

# Direkter Vault-Lookup — umgeht Cascade, geht an den "vault"-Provider
dbPassword: '%secret(vault:kv-v2/database.password)%'
apiToken: '%secret(vault:transit/api_token)%'

# AWS Secrets Manager
dbPassword: '%secret(aws-sm:prod/database.password)%'

 

Format: %secret(provider:path/to/secret.subKey)%

TeilPflichtBeschreibung
providerJaProvider-Name (vault, aws-sm …) — routet direkt
pathNeinSecret-Pfad mit /-Trennern
subKeyNeinJSON-Sub-Key nach letztem . im finalen Pfadsegment

Sub-Key-Extraktion: Liefert ein Provider z. B. {"password":"s3cret","username":"admin"}, extrahiert der Sub-Key password automatisch "s3cret". Einfache Keys (ohne :) funktionieren weiter wie bisher — vollständig rückwärtskompatibel.

Quellcode & Doku

TYPO3 Extension Repository

Nicht im offiziellen TER — Installation ausschließlich über Composer.

Composer-Package

moselwal/secret-resolver via Moselwal-Composer-Repo.

Composer-Repo öffnen

GitLab (Source of Truth)

Primäres Repository inkl. CI/CD und Composer-Package-Registry.

gitlab.moselwal.io

GitHub

Mirror auf GitHub (Platzhalter — vor Publish verifizieren).

github.com/moselwal/secret-resolver
Nächster Schritt

Container-Deployment aufräumen?

secret-resolver ist Open Source und kompakt. Für Vault- oder AWS-Secrets-Manager-Anbindung, Cluster-Setups oder Migration weg von Plain-Text-Secrets unterstützen wir gerne.

Secret-Setup besprechen →

Oder direkt schreiben: kontakt@moselwal.de