tellerops/tellerGestione dei segreti cloud native per sviluppatori - non lasciare mai la tua riga di comando per i segreti.
:computer: Non lasciare mai il tuo terminale per i segreti
:pager: Crea flussi di lavoro semplici e puliti per lavorare con ambienti cloud
:mag_right: Scansiona i segreti e combatti la proliferazione dei segreti
Non lasciare mai il tuo terminale per usare segreti mentre sviluppi, testi e compili le tue app.
Invece di script personalizzati, token nei file .zshrc, EXPORT visibili nella cronologia di bash, file .env.production fuori posto e altro sparsi per la tua workstation — usa semplicemente teller e collegalo a qualsiasi vault, key store o servizio cloud desideri (Teller supporta Hashicorp Vault, AWS Secrets Manager, Google Secret Manager e molti altri).
Puoi usare Teller per riordinare il tuo ambiente personale o per il tuo team come processo e buona pratica.
tellerScarica un binario Scarica un binario dalle release
Compilare dal sorgente Questo metodo ti permetterà di dare un'occhiata al codice sorgente, revisionarlo e compilarne una copia tu stesso.
Questo installerà il binario localmente sulla tua macchina:
$ cd teller-cli
$ cargo install --path .
Crea una nuova configurazione
$ teller new
? Select your secret providers ›
⬚ hashicorp_consul
⬚ aws_secretsmanager
⬚ ssm
⬚ dotenv
⬚ hashicorp
⬚ google_secretmanager
Quindi, modifica il file .teller.yml appena creato per impostare le mappe e le chiavi che ti servono per i tuoi provider.
teller.ymlIl file YAML di teller descrive i tuoi provider e, all'interno di ogni provider, una map che descrive:
id univoco che ti servirà per le operazioni successiveEcco un esempio di file di configurazione. Nota che include anche costrutti di templating, come il recupero di variabili d'ambiente durante il caricamento della configurazione:
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") }}
Ora puoi riferirti a questi provider come hashi_1 o dot_1. Teller recupera i dati specificati da tutti i provider per impostazione predefinita.
Stufo di esportare e impostare manualmente le variabili d'ambiente per eseguire un processo con una configurazione simile a demo/produzione?
Sei stato scottato dall'usare .env.production e dall'esporlo nel progetto locale stesso?
Usando teller e un file .teller.yml che non espone nulla a occhi indiscreti, puoi lavorare in modo fluido e senza interruzioni con zero rischi, e senza bisogno di virgolette:
$ teller run --reset --shell -- node index.js
Questo mostrerà le variabili correnti che teller rileva. Ovviamente, di ciascuna verranno mostrate solo le prime 2 lettere.
$ teller show
Stanco di hardcodare segreti nei tuoi script di shell e dotfile?
In alcuni casi ha senso valutare le variabili nella shell corrente. Ad esempio nel tuo .zshrc ha molto più senso usare teller piuttosto che hardcodarle tutte nel file .zshrc stesso.
In questo caso, ecco cosa dovresti aggiungere:
eval "$(teller sh)"
Stanco di recuperare tutti i tipi di variabili, configurarle e preoccuparti che finiscano anche nella cronologia della tua shell?
Usa questa one-liner d'ora in poi:
$ docker run --rm -it --env-file <(teller env) alpine sh
Teller può aiutarti a combattere la proliferazione dei segreti e i segreti hardcoded, oltre a essere il miglior strumento di produttività per lavorare con il tuo vault.
Può anche integrarsi nella tua CI e fungere da strumento di sicurezza shift-left per la tua pipeline DevSecOps.
Cerca i segreti conservati nel vault all'interno del tuo codice eseguendo:
$ teller scan
Puoi eseguirlo come linter nella tua CI in questo modo:
run: teller scan --error-if-found
Interromperà la build se trova qualcosa (restituisce il codice di uscita 1).
Puoi anche esportare i risultati come JSON con --json e scansionare file binari con -b.
Puoi usare teller come strumento di oscuramento nella tua infrastruttura, eseguire processi oscurando il loro output e anche ripulire log e tail live dei log.
Inoltra tramite pipe qualsiasi output di processo, tail o log a teller per oscurarli in tempo reale:
$ cat some.log | teller redact
Dovrebbe funzionare anche con tail -f:
$ tail -f /var/log/apache.log | teller redact
Infine, se hai dei file da oscurare, puoi farlo anche con:
$ teller redact --in dirty.csv --out clean.csv
Se ometti --in, Teller userà stdin, e se ometti --out, Teller invierà l'output a stdout.
Puoi popolare template personalizzati:
$ teller template --in config-templ.t
Il formato dei template è Tera, molto simile a Liquid o Handlebars.
Ecco un esempio di template:
production_var: {{ key(name="PRINT_NAME")}}
production_mood: {{ key(name="PRINT_MOOD")}}
Nei casi in cui vuoi sincronizzare tra provider, puoi farlo con teller copy.
Sincronizzazione di chiavi di una mappatura specifica
Puoi usare il formato <provider name>/<map id> per copiare una mappatura da un provider a un altro:
$ teller copy --from source/dev --to target/prod,<...>
In questo semplice esempio, usiamo il seguente file di configurazione
providers:
dot1:
kind: dotenv
maps:
- id: one
path: one.env
dot2:
kind: dotenv
maps:
- id: two
path: two.env
Questo:
Per impostazione predefinita, la copia aggiorna la mappatura di destinazione (upsert dei dati); se vuoi sostituire, puoi usare --replace.
I provider di Teller supportano casi d'uso di scrittura che consentono di scrivere valori nei provider.
Ricorda, questa funzionalità ruota comunque attorno alle definizioni nel tuo file teller.yml:
$ teller put --providers new --map-id one NEW_VAR=s33kret
In questo esempio viene utilizzata questa configurazione:
providers:
new:
kind: dotenv
maps:
- id: one
path: new.env
Alcune note:
key=value e puoi specificare più coppie contemporaneamente--providers ti consente di inviare a uno o più provider contemporaneamenteI provider di Teller supportano l'eliminazione di valori dai provider.
$ teller delete --providers new --map-id one DELETE_ME
Alcune note:
--providers ti consente di inviare a uno o più provider contemporaneamenteYAML Esportazione in formato YAMLXXX TODO: riscrivere come funziona il comando export
Puoi esportare in un formato YAML, adatto a GCloud:
$ teller export yaml
Formato di esempio:
FOO: "1"
KEY: VALUE
JSON Esportazione in formato JSONPuoi esportare in un formato JSON, adatto per essere passato tramite pipe a jq o ad altri workflow:
$ teller export json
Formato di esempio:
{
"FOO": "1"
}
Puoi ottenere un elenco dei provider e dei relativi valori di configurazione descritti nella documentazione.
docker su Windows: se hai un test basato su container che usa Docker, assicurati di escluderlo su Windows usando #[cfg(not(windows))]
semantica delle risorse: durante la creazione dei provider, allineati alla semantica di empty e not found come due semantiche distinte: se un provider supporta una semantica esplicita di "not found" (404, NotFound, ecc.), usa Error::NotFound. Altrimenti, quando un provider segnala una semantica "not found" come un insieme di dati vuoto, restituisci un KV[] vuoto (cioè non tradurre una semantica di "empty" in "not found").
I test vengono eseguiti con:
$ cargo test --all --all-features
E richiede Docker (o equivalente) sulla tua macchina.
A tutti i Contributori - siete voi a rendere tutto questo possibile, grazie!
Teller segue il Codice di condotta CNCF
Copyright (c) 2024 @jondot. Vedi LICENSE per ulteriori dettagli.