tellerops/teller開発者向けクラウドネイティブシークレット管理 - シークレットのためにコマンドラインを離れる必要はありません
:computer: シークレットを使うためにターミナルを離れる必要はありません
:pager: クラウド環境で作業するための簡単でクリーンなワークフローを作成します
:mag_right: シークレットをスキャンしてシークレットの蔓延と戦います
開発、テスト、アプリのビルド中にシークレットを使うためにターミナルを離れる必要はありません。
カスタムスクリプト、.zshrc ファイル内のトークン、bash 履歴に残る見える EXPORT、ワークステーション周辺に置き忘れられた .env.production ファイルなどを使う代わりに、teller を使って、お好みのヴォールト、キーストア、クラウドサービスに接続するだけで済みます（Teller は Hashicorp Vault、AWS Secrets Manager、Google Secret Manager などに対応しています）。
Teller は、自分自身の環境を整頓するためにも、チームのプロセスやベストプラクティスとしても使用できます。
teller を使ったクイックスタートバイナリをダウンロード releases からバイナリを入手します。
ソースからビルド この方法を使えば、ソースコードを目視確認し、レビューし、自分でコピーをビルドできます。
これにより、バイナリがローカルマシンにインストールされます：
$ cd teller-cli
$ cargo install --path .
新しい設定を作成
$ teller new
? Select your secret providers ›
⬚ hashicorp_consul
⬚ aws_secretsmanager
⬚ ssm
⬚ dotenv
⬚ hashicorp
⬚ google_secretmanager
次に、新しく作成された .teller.yml を編集して、プロバイダーに必要なマップとキーを設定します。
teller.yml を見てみるteller YAML はプロバイダーを記述し、各プロバイダー内の map は以下を記述します：
id以下は設定ファイルの例です。設定の読み込み中に環境変数を取得するなどのテンプレート構造も含まれていることに注意してください：
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") }}
これらのプロバイダーは、hashi_1 や dot_1 として指定できるようになりました。Teller はデフォルトで、すべてのプロバイダーから指定されたデータを取得します。
デモ用 / 本番用の設定でプロセスを実行するために、環境変数を手動でエクスポートしたり設定したりしていませんか？
.env.production を使用して、ローカルプロジェクト自体に公開してしまい、痛い目にあったことはありませんか？
teller と、詮索する目に何も公開しない .teller.yml ファイルを使えば、ゼロリスクで流暢かつシームレスに作業できます。クォートも必要ありません：
$ teller run --reset --shell -- node index.js
これにより、teller が取得した現在の変数が出力されます。もちろん、各変数の最初の2文字だけが表示されます。
$ teller show
シェルスクリプトや dotfile にシークレットをハードコードしていませんか？
場合によっては、変数を現在のシェルに eval で取り込むのが理にかなっています。例えば .zshrc では、すべてを .zshrc ファイル自体にハードコードするよりも、teller を使う方がはるかに理にかなっています。
その場合、次を追加する必要があります：
eval "$(teller sh)"
あらゆる種類の変数を取得して設定するのにうんざりしていて、それらがシェル履歴に残るのも心配ですか？
今後はこのワンライナーを使いましょう：
$ docker run --rm -it --env-file <(teller env) alpine sh
Teller は、シークレットの蔓延やハードコードされたシークレットへの対策に役立ち、ヴォールトを操作するための最高の生産性ツールにもなります。
また、CI に統合して、DevSecOps パイプラインのシフトレフトセキュリティツールとして機能させることもできます。
次のコマンドを実行して、コード内のヴォールトに保存されたシークレットを探します：
$ teller scan
次のように CI でリンターとして実行できます：
run: teller scan --error-if-found
何か見つかった場合、ビルドを中断します（終了コード 1 を返します）。
また、--json で結果を JSON としてエクスポートしたり、-b でバイナリファイルをスキャンしたりできます。
teller はインフラ全体の redaction ツールとして使用でき、プロセスの出力を伏せ字化しながら実行したり、ログやログのライブテールをクリーンアップしたりできます。
プロセスの出力、tail、ログを teller にパイプすると、それらをライブで伏せ字化できます：
$ cat some.log | teller redact
tail -f でも動作します：
$ tail -f /var/log/apache.log | teller redact
最後に、伏せ字化したいファイルがある場合も、それを行うことができます：
$ teller redact --in dirty.csv --out clean.csv
--in を省略すると Teller は stdin から読み取り、--out を省略すると Teller は stdout に出力します。
カスタムテンプレートに値を埋め込むことができます：
$ teller template --in config-templ.t
テンプレート形式は Tera で、これは liquid や handlebars と非常に似ています。
以下はテンプレートの例です：
production_var: {{ key(name="PRINT_NAME")}}
production_mood: {{ key(name="PRINT_MOOD")}}
プロバイダー間で同期したい場合は、teller copy で行うことができます。
特定のマッピングキーの同期
<provider name>/<map id> 形式を使用して、あるプロバイダーのマッピングを別のプロバイダーにコピーできます：
$ teller copy --from source/dev --to target/prod,<...>
この簡素な例では、次の設定ファイルを使用します：
providers:
dot1:
kind: dotenv
maps:
- id: one
path: one.env
dot2:
kind: dotenv
maps:
- id: two
path: two.env
これにより、次のことを行います：
デフォルトでは、コピーはターゲットマッピングを 更新（upsert）します。置き換えたい場合は --replace を使用してください。
Teller プロバイダーは 書き込み ユースケースをサポートしており、プロバイダー へ 値を書き込むことができます。
この機能は、teller.yml ファイル内の定義に基づいて動作することを忘れないでください：
$ teller put --providers new --map-id one NEW_VAR=s33kret
この例では、次の設定が使用されています：
providers:
new:
kind: dotenv
maps:
- id: one
path: new.env
いくつかの注意点：
key=value 形式のキーと値のペアで、複数のペアを一度に指定できます--providers フラグを使用すると、一度に1つ以上のプロバイダーにプッシュできますTeller プロバイダーは、プロバイダー から 値を 削除する ことをサポートしています。
$ teller delete --providers new --map-id one DELETE_ME
いくつかの注意点：
--providers フラグを使用すると、一度に1つ以上のプロバイダーにプッシュできますYAML YAML 形式でのエクスポートXXX TODO: コマンドエクスポートの仕組みを書き直す
YAML 形式でエクスポートできます。GCloud に適しています：
$ teller export yaml
形式の例：
FOO: "1"
KEY: VALUE
JSON JSON 形式でのエクスポートJSON 形式でエクスポートできます。jq や他のワークフローにパイプするのに適しています：
$ teller export json
形式の例：
{
"FOO": "1"
}
プロバイダーとその設定値の一覧は、ドキュメント で確認できます。
Windows 上の docker: Docker を使用するコンテナベースのテストがある場合は、#[cfg(not(windows))] を使用して Windows 上では除外してください。
リソースのセマンティクス: プロバイダーを構築する際は、空 と 見つからない を2つの異なるセマンティクスとして扱います。プロバイダーが明示的な「見つからない」セマンティクス（404、NotFound など）をサポートしている場合は、Error::NotFound を使用します。それ以外の場合、プロバイダーが「見つからない」セマンティクスを空のデータバッグとして通知するときは、空の KV[] を返します（つまり、「空」のセマンティクスを「見つからない」に変換しないでください）。
テストは次のコマンドで実行します：
$ cargo test --all --all-features
また、マシンに Docker（または同等のもの）が必要です。
すべての Contributors へ - あなたたちがこれを実現しています。ありがとうございます！
Teller は CNCF Code of Conduct に従います。