vaults/secrets management

[jdx]

as the [env] section of config files will very likely contain secrets, there should be a way to manage/encrypt these. I have 2 rough ideas here:

1. support built-in encryption. Allow committing an encrypted config into a repo with a single env var or something used to decrypt it. Maybe there's opportunity for integrating with macos keychain or yubikeys or something like that.
2. support backends. I'm thinking things like hashicorp's vault, macos keychain, and maybe directly integrating with providers like heroku and vercel to pull the env vars from a remote application. Or maybe we do something like dotenv-vault.

Authentication, Authorization and Auditing

[jdx]

on a related note, I've also been thinking that I want a way to share my configs either with myself or others. Right now I'm putting it into my dotfiles repo, but is there an opportunity there to make sharing more of a built-in concept so one wouldn't need a dotfile repo? Also how could one share configs with their team when they don't go into a project?

[reitzig]

ad 2: FWIW, twpayne/chezmoi supports a range of password managers. I'm just starting off using both chezmoi and mise (👋), but I strongly suspect that there's considerable overlap in "adapter" code.

Personally, I would favor approach 2. Sharing files with references to secrets feels way safer than trusting Yet Another Tool™. Plus, not storing a copy (encrypted or not) makes rolling secrets a lot easier.

That said, a personal note on UX. I've written something like

export TOOL_USER="$(op get item "Tool Token" | jq -r '.details.fields[] | select(.name == "username") | .value')"

in an .envrc before, plus bashey sins to authenticate with op. First, if mise can handle that for me, great. Second, asking to unlock the vault when entering a directory can be disruptive; a separate, non-automatic mechanism for loading secrets may be more pragmatic than always resolving secrets. So, in the end, I may just use op run and stick to plain-text references in env files. For 1Password at least, wrapping op may be beyond the point of diminishing returns.

[asmod3us]

I use sops with a direnv plugin. It really hits the smooth spot for me with a single yaml file, shell env vars and/or json/yaml output and using pgp keys. Would be keen to try it in mise!

[hahuang65]

Would like to make a suggestion. Some other tools, such as weechat or aerc, allow password and password_cmd as config options. The latter runs an arbitrary shell command.

This would allow users to use any arbitrary secret storage, provided it has a CLI.

Personally I use keybase for personal stuff, my work place uses Vault as well as AWS SSM.

This would be nice as it wouldn't limit what could be used, and puts the onus of security on the tool/user, rather than something mise would have to maintain.

[roele]

Is the usage of CLIs not already supported via tera templates?

Following assumes VAULT_TOKEN is set somehow already.

[env]
USR="{{exec(command='./vault kv get -address=http://localhost:8200 -mount test -field=usr myapp')}}"

[joshbode]

I'm working on a SOPS plugin for Mise, based heavily on asdf-sops with some stuff borrowed from the poetry plugin, also.

The initial version is here: mise-sops

I'm still playing around with it but so far it's working great for me - the caching is working so it's very fast once the file is loaded.

[tools]
sops =  { version = "3.8", filename = ".foo.env:.bar.env", names="FOO:BAR:BAZ" }
# names optional to filter exported variables

(tool values seem to need to be strings, otherwise I'd make filename a list rather than separating with : :)

All feedback is welcome!