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.
Lembre-se de que esse recurso ainda gira em torno das definições no seu arquivo teller.yml:
$ teller put --providers new --map-id one NEW_VAR=s33kret
Neste exemplo, esta configuração está sendo usada:
providers:
new:
kind: dotenv
maps:
- id: one
path: new.env
Algumas observações:
key=value e você pode especificar vários pares de uma vez--providers permite que você envie para um ou mais provedores de uma só vezOs provedores do Teller suportam a exclusão de valores de provedores.
$ teller delete --providers new --map-id one DELETE_ME
Algumas observações:
--providers permite que você envie para um ou mais provedores de uma só vezYAML Exportar no formato YAMLXXX TODO: reescrever como funciona a exportação do comando
Você pode exportar em um formato YAML, adequado para o GCloud:
$ teller export yaml
Formato de exemplo:
FOO: "1"
KEY: VALUE
JSON Exportar no formato JSONVocê pode exportar em um formato JSON, adequado para usar com jq via pipe ou outros fluxos de trabalho:
$ teller export json
Formato de exemplo:
{
"FOO": "1"
}
Você pode obter uma lista dos provedores e seus valores de configuração descritos na documentação.
docker no windows: se você tiver um teste baseado em contêiner que use Docker, certifique-se de excluí-lo no Windows usando #[cfg(not(windows))]
semântica de recursos: ao construir provedores, alinhe-se com a semântica de vazio e não encontrado como duas semânticas diferentes: se um provedor suportar uma semântica explícita de "não encontrado" (404, NotFound, etc.), use Error::NotFound. Caso contrário, quando um provedor sinalizar uma semântica de "não encontrado" como um conjunto de dados vazio, retorne um KV[] vazio (ou seja, não traduza uma semântica de "vazio" para "não encontrado").
Os testes são feitos com:
$ cargo test --all --all-features
E requer Docker (ou equivalente) na sua máquina.
A todos os Contribuidores - vocês fazem isso acontecer, obrigado!
O Teller segue o Código de Conduta do CNCF
Copyright (c) 2024 @jondot. Consulte o LICENSE para obter mais detalhes.