: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 :

1. Récupérer toutes les valeurs mappées depuis la map source
2. Pour chaque provider cible, trouver la map correspondante et y copier les valeurs depuis la source

Par défaut, la copie met à jour la map cible (upsert des données) ; si vous souhaitez remplacer, vous pouvez utiliser --replace.

🚲 Écriture et multi-écriture vers les providers

Les providers Teller prennent en charge les cas d'usage d'écriture qui permettent d'écrire des valeurs dans les providers.

Rappelez-vous, pour cette fonctionnalité, tout repose toujours sur les définitions de votre fichier teller.yml :

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

Dans cet exemple, cette configuration est utilisée :

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

Quelques remarques :

• Les valeurs sont des paires clé-valeur au format : key=value et vous pouvez spécifier plusieurs paires à la fois
• Lorsque vous spécifiez une valeur sensible littérale, assurez-vous d'utiliser une variable d'environnement afin qu'aucune donnée sensible ne soit enregistrée dans votre historique
• Le drapeau --providers vous permet d'écrire vers un ou plusieurs providers à la fois

❌ Suppression et multi-suppression depuis les providers

Les providers Teller prennent en charge la suppression de valeurs depuis les providers.

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

Quelques remarques :

• Vous pouvez spécifier plusieurs clés à supprimer, par exemple :
• Le drapeau --providers vous permet de cibler un ou plusieurs providers à la fois

YAML Export au format YAML

XXX TODO : réécrire le fonctionnement de la commande export

Vous pouvez exporter au format YAML, adapté à GCloud :

$ teller export yaml

Exemple de format :

FOO: "1"
KEY: VALUE

JSON Export au format JSON

Vous pouvez exporter au format JSON, adapté au passage via jq ou à d'autres flux de travail :

$ teller export json

Exemple de format :

{
  "FOO": "1"
}

Providers

Vous pouvez obtenir la liste des providers et leurs valeurs de configuration décrites dans la documentation.

Liste de contrôle pour les tests :

• docker sur Windows : si vous avez un test basé sur un conteneur qui utilise Docker, assurez-vous de l'exclure sous Windows avec #[cfg(not(windows))]

• sémantique des ressources : lors de la création de providers, alignez-vous sur la sémantique de vide et introuvable comme deux sémantiques distinctes : si un provider prend en charge une sémantique explicite « introuvable » (404, NotFound, etc.), utilisez Error::NotFound. Sinon, lorsqu'un provider signale une sémantique « introuvable » comme un ensemble de données vide, renvoyez un KV[] vide (c'est-à-dire ne traduisez pas une sémantique de « vide » en « introuvable »).

Tests

Les tests sont effectués avec :

$ cargo test --all --all-features

Et nécessitent Docker (ou équivalent) sur votre machine.

Remerciements :

À tous les Contributeurs - c'est grâce à vous, merci !

Code de conduite

Teller suit le Code de conduite CNCF

Copyright

Copyright (c) 2024 @jondot. Voir LICENSE pour plus de détails.