:computer: Verlasse dein Terminal nie wieder für Secrets
:pager: Erstelle einfache und saubere Workflows für den Umgang mit Cloud-Umgebungen
:mag_right: Suche nach Secrets und bekämpfe Secret-Sprawl

Teller – der quelloffene universelle Secret-Manager für Entwickler

Verlasse dein Terminal nie, um Secrets zu nutzen, während du deine Apps entwickelst, testest und baust.

Statt eigener Skripte, Tokens in deinen .zshrc-Dateien, sichtbaren EXPORTs in deiner Bash-Historie, verlegter .env.production-Dateien und mehr auf deiner Workstation – nutze einfach teller und verbinde es mit beliebigen Vaults, Schlüsselspeichern oder Cloud-Diensten (Teller unterstützt Hashicorp Vault, AWS Secrets Manager, Google Secret Manager und viele mehr).

Du kannst Teller nutzen, um deine eigene Umgebung aufzuräumen oder als Prozess und Best Practice für dein Team.

Schnellstart mit `teller`

Ein Binary herunterladen Hole dir ein Binary von den Releases

Aus dem Quellcode bauen Mit dieser Methode kannst du den Quellcode selbst in Augenschein nehmen, prüfen und eine eigene Kopie bauen.

Dadurch wird das Binary lokal auf deinem Rechner installiert:

$ cd teller-cli
$ cargo install --path .

Neue Konfiguration erstellen

$ teller new
? Select your secret providers ›
⬚ hashicorp_consul
⬚ aws_secretsmanager
⬚ ssm
⬚ dotenv
⬚ hashicorp
⬚ google_secretmanager

Danach bearbeite die neu erstellte .teller.yml, um die Maps und Keys festzulegen, die du für deine Provider benötigst.

Ein Blick auf `teller.yml`

Die teller-YAML beschreibt deine Provider und innerhalb jedes Providers eine map, die Folgendes beschreibt:

Den Root-Pfad, aus dem Schlüssel-Wert-Paare geholt werden
Für jede solche Map eine eindeutige id, die dir für spätere Operationen dient
Für jede Map ein optionales spezifisches Schlüssel-Mapping – du kannst Schlüssel, die du aus dem Quell-Provider holst, umbenennen

Hier ist eine Beispielkonfigurationsdatei. Beachte, dass sie auch Template-Konstrukte enthält – etwa das Holen von Umgebungsvariablen beim Laden der Konfiguration:

providers:
  hashi_1:
    kind: hashicorp
    maps:
      - id: test-load
        path: /{{ get_env(name="TEST_LOAD_1", default="test") }}/users/user1
        # if empty, map everything
        # == means map to same key name
        # otherwise key on left becomes right
        # in the future: key_transform: camelize, snake_case for automapping the keys
        keys:
          GITHUB_TOKEN: ==
          mg: FOO_BAR
  dot_1:
    kind: dotenv
    maps:
      - id: stg
        path: VAR_{{ get_env(name="STAGE", default="development") }}

Du kannst diese Provider nun als hashi_1 oder dot_1 ansprechen. Teller zieht standardmäßig die angegebenen Daten von allen Providern.

Features

🏃 Subprozesse ausführen

Exportierst du und richtest Umgebungsvariablen manuell ein, um einen Prozess mit Demo-/Produktions-Setup auszuführen?

Hattest du Probleme, weil .env.production verwendet und im lokalen Projekt selbst offengelegt wurde?

Mit teller und einer .teller.yml-Datei, die neugierigen Blicken nichts preisgibt, kannst du flüssig und nahtlos mit null Risiko arbeiten – auch ohne Anführungszeichen:

$ teller run --reset --shell -- node index.js

🔎 Variablen anzeigen

Das gibt die aktuellen Variablen aus, die teller aufnimmt. Von jeder werden natürlich nur die ersten 2 Buchstaben angezeigt.

$ teller show

📺 Lokale Shell-Befüllung

Hardcodierst du Secrets in deine Shell-Skripte und Dotfiles?

In manchen Fällen ist es sinnvoll, Variablen in deine aktuelle Shell zu evaluieren. Zum Beispiel ergibt es in deiner .zshrc viel mehr Sinn, teller zu nutzen, statt all das direkt in die .zshrc-Datei zu hardcodieren.

In diesem Fall solltest du Folgendes hinzufügen:

eval "$(teller sh)"

🐳 Einfache Docker-Umgebung

Bist du es leid, alle möglichen Variablen zusammenzuklauben, einzurichten und dir Sorgen zu machen, dass diese auch in deiner Shell-Historie auftauchen?

Nutze ab jetzt diesen Einzeiler:

$ docker run --rm -it --env-file <(teller env) alpine sh

⚠️ Nach Secrets scannen

Teller kann dir helfen, Secret-Sprawl und hartcodierte Secrets zu bekämpfen und ist das beste Produktivitätswerkzeug für die Arbeit mit deinem Vault.

Es lässt sich außerdem in deine CI integrieren und als Shift-Left-Sicherheitswerkzeug für deine DevSecOps-Pipeline einsetzen.

Suche in deinem Code nach den in deinem Vault aufbewahrten Secrets, indem du Folgendes ausführst:

$ teller scan

Du kannst es als Linter in deiner CI ausführen, zum Beispiel so:

run: teller scan --error-if-found

Es bricht deinen Build ab, wenn es etwas findet (Rückgabecode 1).

Du kannst Ergebnisse auch mit --json als JSON exportieren und mit -b Binärdateien scannen.

♻️ Secrets aus Prozessausgaben, Logs und Dateien schwärzen

Du kannst teller als Schwärzungswerkzeug in deiner gesamten Infrastruktur einsetzen und Prozesse ausführen, während ihre Ausgabe geschwärzt wird. Außerdem kannst du Logs und Live-Mitläufe von Logs bereinigen.

Leite eine beliebige Prozessausgabe, ein Log-Tail oder Logs in teller, um sie live zu schwärzen:

$ cat some.log | teller redact

Das sollte auch mit tail -f funktionieren:

$ tail -f /var/log/apache.log | teller redact

Und wenn du Dateien hast, die du schwärzen möchtest, kannst du das ebenfalls tun:

$ teller redact --in dirty.csv --out clean.csv

Wenn du --in weglässt, nimmt Teller stdin, und wenn du --out weglässt, gibt Teller auf stdout aus.

📜 Templates befüllen

Du kannst benutzerdefinierte Templates befüllen:

$ teller template --in config-templ.t

Das Template-Format ist Tera, das Liquid oder Handlebars sehr ähnlich ist.

Hier ist ein Beispieltemplate:

production_var: {{ key(name="PRINT_NAME")}}
production_mood: {{ key(name="PRINT_MOOD")}}

🔄 Daten zwischen Providern kopieren/synchronisieren

Wenn du zwischen Providern synchronisieren möchtest, kannst du das mit teller copy tun.

Synchronisierung eines bestimmten Mappings

Du kannst das Format <Providername>/<Map-ID> verwenden, um ein Mapping von einem Provider zu einem anderen zu kopieren:

$ teller copy --from source/dev --to target/prod,<...>

In diesem vereinfachten Beispiel verwenden wir die folgende Konfigurationsdatei:

providers:
  dot1:
    kind: dotenv
    maps:
      - id: one
        path: one.env
  dot2:
    kind: dotenv
    maps:
      - id: two
        path: two.env

Das wird Folgendes tun:

Alle gemappten Werte aus dem Quell-Mapping holen
Für jeden Ziel-Provider das passende Mapping finden und die Werte aus der Quelle hineinkopieren

Standardmäßig aktualisiert das Kopieren das Ziel-Mapping (Upsert-Daten); wenn du ersetzen möchtest, kannst du --replace verwenden.

🚲 Schreiben und Mehrfach-Schreiben in Provider

Teller-Provider unterstützen Schreib-Anwendungsfälle, die das Schreiben von Werten in Provider ermöglichen.

Denk daran, dass es auch bei dieser Funktion um die Definitionen in deiner teller.yml-Datei geht:

$ teller put --providers new --map-id one NEW_VAR=s33kret

In diesem Beispiel wird diese Konfiguration verwendet:

providers:
  new:
    kind: dotenv
    maps:
      - id: one
        path: new.env

Ein paar Hinweise:

Werte sind Schlüssel-Wert-Paare im Format key=value und du kannst mehrere Paare gleichzeitig angeben
Wenn du einen literalen sensiblen Wert angibst, stelle sicher, dass du eine ENV-Variable verwendest, damit nichts Sensibles in deiner Historie aufgezeichnet wird
Mit dem Flag --providers kannst du an einen oder mehrere Provider gleichzeitig übertragen

❌ Löschen und Mehrfach-Löschen aus Providern

Teller-Provider unterstützen das Löschen von Werten aus Providern.

$ teller delete --providers new --map-id one DELETE_ME

Ein paar Hinweise:

Du kannst mehrere zu löschende Schlüssel angeben, zum Beispiel:
Mit dem Flag --providers kannst du bei einem oder mehreren Providern gleichzeitig löschen

`YAML` Export im YAML-Format

XXX TODO: Umschreiben, wie der Export-Befehl funktioniert

Du kannst in einem YAML-Format exportieren, geeignet für GCloud:

$ teller export yaml

Beispielformat:

FOO: "1"
KEY: VALUE

`JSON` Export im JSON-Format

Du kannst in einem JSON-Format exportieren, geeignet zum Durchleiten durch jq oder andere Workflows:

$ teller export json

Beispielformat:

{
  "FOO": "1"
}

Provider

Eine Liste der Provider und ihrer beschriebenen Konfigurationswerte findest du in der Dokumentation.

Test-Checkliste:

Docker auf Windows: Wenn du einen containerbasierten Test hast, der Docker verwendet, stelle sicher, dass du ihn unter Windows mit #[cfg(not(windows))] ausschließt.
Ressourcen-Semantik: Richte dich beim Bauen von Providern nach der Semantik von leer und nicht gefunden als zwei unterschiedlichen Semantiken: Wenn ein Provider eine explizite „nicht gefunden“-Semantik unterstützt (404, NotFound usw.), verwende Error::NotFound. Wenn ein Provider eine „nicht gefunden“-Semantik als leere Datenmenge signalisiert, gib ein leeres KV[] zurück (d. h. übersetze eine „leer“-Semantik nicht in „nicht gefunden“).

Testen

Getestet wird mit:

$ cargo test --all --all-features

Dafür wird Docker (oder Äquivalentes) auf deinem Rechner benötigt.

Danksagung:

An alle Contributors – ihr macht das möglich, danke!

Verhaltenskodex

Teller folgt dem CNCF Code of Conduct

teller

Beliebteste