tellerops/tellerGestión de secretos nativa de la nube para desarrolladores: nunca abandones tu línea de comandos por los secretos.
:computer: Nunca dejes tu terminal por los secretos
:pager: Crea flujos de trabajo fáciles y limpios para trabajar con entornos en la nube
:mag_right: Escanea en busca de secretos y combate la dispersión de secretos
Nunca dejes tu terminal para usar secretos mientras desarrollas, pruebas y compilas tus aplicaciones.
En lugar de scripts personalizados, tokens en tus archivos .zshrc, EXPORTs visibles en tu historial de bash, archivos .env.production mal ubicados y más cosas por tu estación de trabajo, simplemente usa teller y conéctalo a cualquier vault, almacén de claves o servicio en la nube que quieras (Teller es compatible con Hashicorp Vault, AWS Secrets Manager, Google Secret Manager y muchos más).
Puedes usar Teller para ordenar tu propio entorno o para tu equipo como proceso y buena práctica.
tellerDescarga un binario Consigue un binario desde releases
Compila desde el código fuente Usar este método te permitirá echar un vistazo al código fuente, revisarlo y compilar una copia tú mismo.
Esto instalará el binario localmente en tu máquina:
$ cd teller-cli
$ cargo install --path .
Crea una nueva configuración
$ teller new
? Select your secret providers ›
⬚ hashicorp_consul
⬚ aws_secretsmanager
⬚ ssm
⬚ dotenv
⬚ hashicorp
⬚ google_secretmanager
Luego, edita el .teller.yml recién creado para definir los mapas y las claves que necesites para tus proveedores.
teller.ymlEl YAML de teller describe tus proveedores y, dentro de cada proveedor, un map que describe:
id único, que te servirá para operaciones posterioresAquí tienes un archivo de configuración de ejemplo. Ten en cuenta que también incluye construcciones de plantillas, como obtener variables de entorno al cargar la configuración:
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") }}
Ahora puedes referirte a estos proveedores como hashi_1 o dot_1. Teller obtiene los datos especificados de todos los proveedores por defecto.
¿Exportando y configurando manualmente variables de entorno para ejecutar un proceso con una configuración tipo demo o tipo producción?
¿Te ha pasado factura usar .env.production y exponerlo en el propio proyecto local?
Con teller y un archivo .teller.yml que no expone nada a las miradas indiscretas, puedes trabajar con fluidez y sin fricciones, con cero riesgo y sin necesidad de comillas:
$ teller run --reset --shell -- node index.js
Esto mostrará las variables actuales que teller detecta. Por supuesto, solo se mostrarán las 2 primeras letras de cada una.
$ teller show
¿Codificando secretos directamente en tus scripts de shell y dotfiles?
En algunos casos tiene sentido evaluar variables en tu shell actual. Por ejemplo, en tu .zshrc tiene mucho más sentido usar teller y no codificar todas esas variables en el propio archivo .zshrc.
En este caso, esto es lo que deberías añadir:
eval "$(teller sh)"
¿Cansado de recoger todo tipo de variables, configurarlas y preocupado además de que aparezcan en tu historial de shell?
Usa esta línea única de ahora en adelante:
$ docker run --rm -it --env-file <(teller env) alpine sh
Teller puede ayudarte a combatir la dispersión de secretos y los secretos codificados, además de ser la mejor herramienta de productividad para trabajar con tu vault.
También puede integrarse en tu CI y servir como herramienta de seguridad shift-left para tu pipeline de DevSecOps.
Busca los secretos guardados en tu vault dentro de tu código ejecutando:
$ teller scan
Puedes ejecutarlo como linter en tu CI de la siguiente manera:
run: teller scan --error-if-found
Romperá tu compilación si encuentra algo (devuelve el código de salida 1).
También puedes exportar los resultados como JSON con --json y escanear archivos binarios con -b.
Puedes usar teller como herramienta de redacción en toda tu infraestructura, y ejecutar procesos mientras se redacta su salida, además de limpiar registros y colas de registros en vivo.
Pasa cualquier salida de proceso, cola o registros a teller para redactarlos en vivo:
$ cat some.log | teller redact
También debería funcionar con tail -f:
$ tail -f /var/log/apache.log | teller redact
Por último, si tienes algunos archivos que quieras redactar, también puedes hacerlo:
$ teller redact --in dirty.csv --out clean.csv
Si omites --in, Teller tomará stdin, y si omites --out, Teller enviará la salida a stdout.
Puedes rellenar plantillas personalizadas:
$ teller template --in config-templ.t
El formato de plantilla es Tera, que es muy similar a Liquid o Handlebars.
Aquí tienes una plantilla de ejemplo:
production_var: {{ key(name="PRINT_NAME")}}
production_mood: {{ key(name="PRINT_MOOD")}}
En los casos en los que quieras sincronizar entre proveedores, puedes hacerlo con teller copy.
Sincronización de claves de un mapeo específico
Puedes usar el formato <provider name>/<map id> para copiar un mapeo de un proveedor a otro:
$ teller copy --from source/dev --to target/prod,<...>
En este ejemplo simplista, usamos el siguiente archivo de configuración
providers:
dot1:
kind: dotenv
maps:
- id: one
path: one.env
dot2:
kind: dotenv
maps:
- id: two
path: two.env
Esto:
Por defecto, la copia actualizará el mapeo de destino (upsert de datos); si quieres reemplazar, puedes usar --replace.
Los proveedores de Teller admiten casos de uso de escritura que permiten escribir valores en los proveedores.
Recuerda que esta función sigue girando en torno a las definiciones de tu archivo teller.yml:
$ teller put --providers new --map-id one NEW_VAR=s33kret
En este ejemplo, se está usando esta configuración:
providers:
new:
kind: dotenv
maps:
- id: one
path: new.env
Algunas notas:
key=value y puedes especificar varios pares a la vez--providers te permite enviar a uno o más proveedores a la vezLos proveedores de Teller admiten eliminar valores de los proveedores.
$ teller delete --providers new --map-id one DELETE_ME
Algunas notas:
--providers te permite enviar a uno o más proveedores a la vezYAML Exportación en formato YAMLXXX TODO: reescribir cómo funciona la exportación del comando
Puedes exportar en formato YAML, adecuado para GCloud:
$ teller export yaml
Formato de ejemplo:
FOO: "1"
KEY: VALUE
JSON Exportación en formato JSONPuedes exportar en formato JSON, adecuado para procesarlo con jq u otros flujos de trabajo:
$ teller export json
Formato de ejemplo:
{
"FOO": "1"
}
Puedes obtener una lista de los proveedores y sus valores de configuración descritos en la documentación.
docker en windows: si tienes una prueba basada en contenedores que usa Docker, asegúrate de excluirla en Windows usando #[cfg(not(windows))]
semántica de recursos: al construir proveedores, alinéate con las semánticas de vacío y no encontrado como dos semánticas diferentes: si un proveedor admite una semántica explícita de "no encontrado" (404, NotFound, etc.), usa Error::NotFound. De lo contrario, cuando un proveedor señale una semántica de "no encontrado" como una bolsa de datos vacía, devuelve un KV[] vacío (es decir, no traduzcas una semántica de "vacío" a "no encontrado").
Las pruebas se realizan con:
$ cargo test --all --all-features
Y requiere Docker (o equivalente) en tu máquina.
A todos los Contribuidores: vosotros hacéis que esto sea posible, ¡gracias!
Teller sigue el Código de Conducta de CNCF
Copyright (c) 2024 @jondot. Consulta LICENSE para más detalles.