tellerops/tellerGerenciamento de segredos nativo da nuvem para desenvolvedores — nunca saia da sua linha de comando para lidar com segredos.
:computer: Nunca saia do seu terminal para usar segredos
:pager: Crie fluxos de trabalho fáceis e limpos para trabalhar com ambientes de nuvem
:mag_right: Digitalize em busca de segredos e combata a proliferação de segredos
Nunca saia do seu terminal para usar segredos ao desenvolver, testar e compilar seus aplicativos.
Em vez de scripts personalizados, tokens nos seus arquivos .zshrc, EXPORTs visíveis no seu histórico do bash, arquivos .env.production fora do lugar e mais coisas pela sua estação de trabalho -- basta usar o teller e conectá-lo a qualquer cofre, armazenamento de chaves ou serviço de nuvem que você quiser (o Teller suporta Hashicorp Vault, AWS Secrets Manager, Google Secret Manager e muitos outros).
Você pode usar o Teller para organizar seu próprio ambiente ou, para sua equipe, como um processo e uma melhor prática.
tellerBaixe um binário Pegue um binário nas releases
Compile a partir do código-fonte Usar este método permitirá que você examine o código-fonte, revise-o e compile uma cópia você mesmo.
Isso instalará o binário localmente na sua máquina:
$ cd teller-cli
$ cargo install --path .
Crie uma nova configuração
$ teller new
? Select your secret providers ›
⬚ hashicorp_consul
⬚ aws_secretsmanager
⬚ ssm
⬚ dotenv
⬚ hashicorp
⬚ google_secretmanager
Em seguida, edite o .teller.yml recém-criado para definir os mapas e as chaves de que você precisa para seus provedores.
teller.ymlO YAML do teller descreve seus provedores e, dentro de cada provedor, um map que descreve:
id exclusivo, que servirá para operações futurasAqui está um exemplo de arquivo de configuração. Observe que ele também inclui construções de templating -- como buscar variáveis de ambiente ao carregar a configuração:
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") }}
Agora você pode se referir a esses provedores como hashi_1 ou dot_1. O Teller busca os dados especificados de todos os provedores por padrão.
Exportar e configurar manualmente variáveis de ambiente para executar um processo com uma configuração semelhante a demo / produção?
Já foi prejudicado por usar .env.production e expô-lo no próprio projeto local?
Usando o teller e um arquivo .teller.yml que não expõe nada a olhos curiosos, você pode trabalhar com fluidez e sem interrupções, com zero risco e sem precisar de aspas:
$ teller run --reset --shell -- node index.js
Isso exibirá as variáveis atuais que o teller capta. Apenas as 2 primeiras letras de cada uma serão mostradas, é claro.
$ teller show
Cansado de codificar segredos diretamente nos seus scripts de shell e dotfiles?
Em alguns casos, faz sentido usar eval para carregar variáveis no shell atual. Por exemplo, no seu .zshrc faz muito mais sentido usar o teller do que codificar todas essas variáveis diretamente no próprio arquivo .zshrc.
Nesse caso, é isto que você deve adicionar:
eval "$(teller sh)"
Cansado de coletar todos os tipos de variáveis, configurá-las e ainda preocupado com elas aparecerem no seu histórico do shell?
Use este comando de uma linha a partir de agora:
$ docker run --rm -it --env-file <(teller env) alpine sh
O Teller pode ajudar você a combater a proliferação de segredos e segredos codificados, além de ser a melhor ferramenta de produtividade para trabalhar com seu cofre.
Ele também pode ser integrado ao seu CI e servir como uma ferramenta de segurança shift-left para seu pipeline de DevSecOps.
Procure por segredos guardados no seu cofre dentro do seu código executando:
$ teller scan
Você pode executá-lo como um linter no seu CI da seguinte forma:
run: teller scan --error-if-found
Ele interromperá seu build se encontrar algo (retorna o código de saída 1).
Você também pode exportar resultados como JSON com --json e verificar arquivos binários com -b.
Você pode usar o teller como uma ferramenta de ocultação de dados (redaction) em toda a sua infraestrutura, executar processos enquanto oculta suas saídas e também limpar logs e acompanhamentos de logs em tempo real (tails).
Envie via pipe qualquer saída de processo, tail ou logs para o teller para ocultá-los ao vivo:
$ cat some.log | teller redact
Também deve funcionar com tail -f:
$ tail -f /var/log/apache.log | teller redact
Por fim, se você tiver alguns arquivos que deseja ocultar, também pode fazer isso:
$ teller redact --in dirty.csv --out clean.csv
Se você omitir --in, o Teller usará stdin; e se omitir --out, o Teller enviará a saída para stdout.
Você pode preencher modelos personalizados:
$ teller template --in config-templ.t
O formato do modelo é Tera, que é muito semelhante a Liquid ou Handlebars.
Aqui está um exemplo de modelo:
production_var: {{ key(name="PRINT_NAME")}}
production_mood: {{ key(name="PRINT_MOOD")}}
Nos casos em que você quiser sincronizar entre provedores, pode fazer isso com teller copy.
Sincronização específica de mapeamento de chaves
Você pode usar o formato <provider name>/<map id> para copiar um mapeamento de um provedor para outro:
$ teller copy --from source/dev --to target/prod,<...>
Neste exemplo simplista, usamos o seguinte arquivo de configuração
providers:
dot1:
kind: dotenv
maps:
- id: one
path: one.env
dot2:
kind: dotenv
maps:
- id: two
path: two.env
Isso irá:
Por padrão, a cópia atualiza o mapeamento de destino (faz upsert dos dados); se você quiser substituir, use --replace.
Os provedores do Teller suportam casos de uso de escrita, que permitem gravar valores em provedores.