💻 Never leave your terminal for secrets
📟 Create easy and clean workflows for working with cloud environments
🔎 Scan for secrets and fight secret sprawl
Never leave your terminal to use secrets while developing, testing, and building your apps.
Instead of custom scripts, tokens in your .zshrc files, visible EXPORTs in your bash history, misplaced .env.production files and more around your workstation -- just use teller and connect it to any vault, key store, or cloud service you like (Teller support Hashicorp Vault, AWS Secrets Manager, Google Secret Manager, and many more).
You can use Teller to tidy your own environment or for your team as a process and best practice.
Download a binary Grab a binary from releases
Build from source Using this method will allow you to eye-ball the source code, review it, and build a copy yourself.
This will install the binary locally on your machine:
$ cd teller-cli
$ cargo install --path .Create a new configuration
$ teller new
? Select your secret providers ›
⬚ hashicorp_consul
⬚ aws_secretsmanager
⬚ ssm
⬚ dotenv
⬚ hashicorp
⬚ google_secretmanager
Then, edit the newly created .teller.yml to set the maps and keys that you need for your providers.
The teller YAML describes your providers and within each provider a map that describes:
- What is the root path to fetch key-values from
- For each such map, its unique
idwhich will serve you for operations later - For each map, an optional specific key name mapping - you can rename keys that you will fetch from the source provider
Here's an example configuration file. Note that it also include templating constructs -- such as fetching environment variables while loading the 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") }}
You can now address these providers as hashi_1 or dot_1. Teller pulls the specified data from all providers by default.
Manually exporting and setting up environment variables for running a process with demo-like / production-like set up?
Got bitten by using .env.production and exposing it in the local project itself?
Using teller and a .teller.yml file that exposes nothing to the prying eyes, you can work fluently and seamlessly with zero risk, also no need for quotes:
$ teller run --reset --shell -- node index.js
This will output the current variables teller picks up. Only first 2 letters will be shown from each, of course.
$ teller show
Hardcoding secrets into your shell scripts and dotfiles?
In some cases it makes sense to eval variables into your current shell. For example in your .zshrc it makes much more sense to use teller, and not hardcode all those into the .zshrc file itself.
In this case, this is what you should add:
eval "$(teller sh)"
Tired of grabbing all kinds of variables, setting those up, and worried about these appearing in your shell history as well?
Use this one liner from now on:
$ docker run --rm -it --env-file <(teller env) alpine sh
Teller can help you fight secret sprawl and hard coded secrets, as well as be the best productivity tool for working with your vault.
It can also integrate into your CI and serve as a shift-left security tool for your DevSecOps pipeline.
Look for your vault-kept secrets in your code by running:
$ teller scanYou can run it as a linter in your CI like so:
run: teller scan --error-if-foundIt will break your build if it finds something (returns exit code 1).
You can also export results as JSON with --json and scan binary files with -b.
You can use teller as a redaction tool across your infrastructure, and run processes while redacting their output as well as clean up logs and live tails of logs.
Pipe any process output, tail or logs into teller to redact those, live:
$ cat some.log | teller redact
It should also work with tail -f:
$ tail -f /var/log/apache.log | teller redact
Finally, if you've got some files you want to redact, you can do that too:
$ teller redact --in dirty.csv --out clean.csvIf you omit --in Teller will take stdin, and if you omit --out Teller will output to stdout.
You can populate custom templates:
$ teller template --in config-templ.tTemplate format is Tera which is very similar to liquid or handlebars.
Here is an example template:
production_var: {{ key(name="PRINT_NAME")}}
production_mood: {{ key(name="PRINT_MOOD")}}In cases where you want to sync between providers, you can do that with teller copy.
Specific mapping key sync
You can use the <provider name>/<map id> format to copy a mapping from a provider to another provider:
$ teller copy --from source/dev --to target/prod,<...>In this simplistic example, we use the following configuration file
providers:
dot1:
kind: dotenv
maps:
- id: one
path: one.env
dot2:
kind: dotenv
maps:
- id: two
path: two.envThis will:
- Grab all mapped values from source mapping
- For each target provider, find the matching mapping, and copy the values from source into it
By default copying will update target mapping (upsert data), if you want to replace you can use --replace.
Teller providers supporting write use cases which allow writing values into providers.
Remember, for this feature it still revolves around definitions in your teller.yml file:
$ teller put --providers new --map-id one NEW_VAR=s33kretIn this example, this configuration is being used:
providers:
new:
kind: dotenv
maps:
- id: one
path: new.envA few notes:
- Values are key-value pair in the format:
key=valueand you can specify multiple pairs at once - When you're specifying a literal sensitive value, make sure to use an ENV variable so that nothing sensitive is recorded in your history
- The flag
--providerslets you push to one or more providers at once
Teller providers support deleting values from providers.
$ teller delete --providers new --map-id one DELETE_MEA few notes:
- You can specify multiple keys to delete, for example:
- The flag
--providerslets you push to one or more providers at once
XXX TODO: rewrite how the command export works
You can export in a YAML format, suitable for GCloud:
$ teller export yaml
Example format:
FOO: "1"
KEY: VALUEYou can export in a JSON format, suitable for piping through jq or other workflows:
$ teller export json
Example format:
{
"FOO": "1"
}You can get a list of the providers and their described configuration values in the documentation.
-
docker on windows: if you have a container based test that uses Docker, make sure to exclude it on Windows using
#[cfg(not(windows))] -
resource semantics: while building providers, align with the semantics of empty and not found as two different semantics: if a provider supports an explicit "not found" semantic (404, NotFound, etc.), use
Error::NotFound. Otherwise when a provider signals a "not found" semantic as an empty data bag, return an emptyKV[](i.e. do not translate a sematic of "empty" into "not found").
Testing is done with:
$ cargo test --all --all-features
And requires Docker (or equivalent) on your machine.
To all Contributors - you make this happen, thanks!
Teller follows CNCF Code of Conduct
Copyright (c) 2024 @jondot. See LICENSE for further details.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent