:computer: Ne quittez jamais votre terminal pour vos secrets
:pager: Créez des flux de travail simples et propres pour travailler avec des environnements cloud
:mag_right: Recherchez des secrets et luttez contre la dispersion des secrets

---

Teller - le gestionnaire de secrets universel open-source pour développeurs

Ne quittez jamais votre terminal pour utiliser des secrets lors du développement, des tests et de la construction de vos applications.

Au lieu de scripts personnalisés, de jetons dans vos fichiers .zshrc, de EXPORT visibles dans votre historique bash, de fichiers .env.production égarés et d'autres éléments dispersés sur votre poste de travail — utilisez simplement teller et connectez-le à n'importe quel coffre-fort, magasin de clés ou service cloud de votre choix (Teller prend en charge Hashicorp Vault, AWS Secrets Manager, Google Secret Manager, et bien d'autres).

Vous pouvez utiliser Teller pour organiser votre propre environnement ou pour votre équipe, en tant que processus et bonne pratique.

Démarrage rapide avec teller

Télécharger un binaire Récupérez un binaire depuis les releases

Compiler depuis les sources Cette méthode vous permettra de jeter un œil au code source, de le revoir et d'en construire une copie vous-même.

Ceci installera le binaire localement sur votre machine :

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

Créer une nouvelle configuration

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

Ensuite, modifiez le fichier .teller.yml nouvellement créé pour définir les maps et les clés nécessaires à vos providers.

Un aperçu de teller.yml

Le YAML de teller décrit vos providers et, au sein de chaque provider, une map qui décrit :

• Quel est le chemin racine pour récupérer les paires clé-valeur
• Pour chaque map, son id unique qui vous servira pour les opérations ultérieures
• Pour chaque map, un mappage de noms de clés spécifique et optionnel — vous pouvez renommer les clés que vous récupérez depuis le provider source

Voici un exemple de fichier de configuration. Notez qu'il inclut également des constructions de templating — comme la récupération de variables d'environnement lors du chargement de la configuration :

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") }}

Vous pouvez désormais désigner ces providers comme hashi_1 ou dot_1. Par défaut, Teller récupère les données spécifiées depuis tous les providers.

Fonctionnalités

🏃 Exécution de sous-processus

Exporter et configurer manuellement des variables d'environnement pour exécuter un processus avec une configuration de type démo / production ?

Vous êtes déjà tombé sur le fait d'utiliser .env.production et de l'exposer dans le projet local lui-même ?

En utilisant teller et un fichier .teller.yml qui n'expose rien aux regards indiscrets, vous pouvez travailler de manière fluide et transparente avec zéro risque, et sans avoir besoin de guillemets :

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

🔎 Inspection des variables

Ceci affichera les variables actuelles que teller récupère. Seules les 2 premières lettres de chacune seront affichées, bien sûr.

$ teller show

📺 Peuplement du shell local

Vous codez en dur des secrets dans vos scripts shell et vos dotfiles ?

Dans certains cas, il est logique d'évaluer des variables dans votre shell courant. Par exemple, dans votre .zshrc, il est bien plus pertinent d'utiliser teller plutôt que de coder en dur tout cela dans le fichier .zshrc lui-même.

Dans ce cas, voici ce que vous devriez ajouter :

eval "$(teller sh)"

🐳 Environnement Docker simplifié

Fatigué de récupérer toutes sortes de variables, de les configurer, et de craindre qu'elles apparaissent également dans votre historique shell ?

Utilisez cette commande en une ligne à partir de maintenant :

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

⚠️ Recherche de secrets

Teller peut vous aider à lutter contre la dispersion des secrets et les secrets codés en dur, tout en étant le meilleur outil de productivité pour travailler avec votre coffre-fort.

Il peut également s'intégrer à votre CI et servir d'outil de sécurité shift-left pour votre pipeline DevSecOps.

Recherchez les secrets conservés dans votre coffre-fort dans votre code en exécutant :

$ teller scan

Vous pouvez l'exécuter comme un linter dans votre CI comme ceci :

run: teller scan --error-if-found

Il cassera votre build s'il trouve quelque chose (retourne le code de sortie 1).

Vous pouvez également exporter les résultats au format JSON avec --json et analyser les fichiers binaires avec -b.

♻️ Masquer les secrets dans les sorties de processus, les journaux et les fichiers

Vous pouvez utiliser teller comme outil de masquage à travers votre infrastructure, et exécuter des processus tout en masquant leur sortie, ainsi que nettoyer les journaux et les flux continus de journaux.

Passez toute sortie de processus, tail ou journal dans teller pour les masquer, en direct :

$ cat some.log | teller redact

Cela devrait également fonctionner avec tail -f :

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

Enfin, si vous avez des fichiers à masquer, vous pouvez également le faire :

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

Si vous omettez --in, Teller utilisera stdin, et si vous omettez --out, Teller écrira sur stdout.

📜 Remplir des modèles

Vous pouvez remplir des modèles personnalisés :

$ teller template --in config-templ.t

Le format de modèle est Tera, très similaire à Liquid ou Handlebars.

Voici un exemple de modèle :

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

🔄 Copier/synchroniser des données entre providers

Dans les cas où vous souhaitez synchroniser des providers, vous pouvez le faire avec teller copy.

Synchronisation d'une map spécifique

Vous pouvez utiliser le format <nom du provider>/<id de la map> pour copier une map d'un provider vers un autre provider :

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

Dans cet exemple simpliste, nous utilisons le fichier de configuration suivant :

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

Cela va :