Templated Secrets

[comminutus]

Hello, I recently started using chezmoi and I am thoroughly impressed! I added most of my dot files and put my .ssh directory on hold until now. I discovered a few different blog articles that suggest using a password manager to store the SSH private keys and using chezmoi templates to populate the actual secrets.

I tried this using BitWarden, but soon after I got it to work almost every chezmoi command wanted me to login to BitWarden so that the templates could be reconciled (status, verify, etc.).

I came across issue #2888 and it seems like a similar pain point I'm having. I don't think it's a good idea to have an exposed session key in an environment variable all the time, particularly when it's rarely needed. I understand that there's no way for chezmoi to reconcile the source and target without using the password, but most of the time those files rarely change.

I tried doing the suggested workaround of adding the key to the ignore list if it already exists, but when you have several keys to add it seems a bit tedious. The key name has to be repeated both in the templating logic as well as in the template output itself (not very DRY).

Another thought I had is just to simply check the keys into source control as long as the private keys are encrypted with a password, but I realize that's not good practice since it opens the key up to brute-force attacks should the key be obtained via git. This is similar to using something like Mozilla SOPS or encrypting the data before it's checked in.

It'd be nice to slice off specific files from always being reconciled, in some sort of context/namespace. Perhaps a property within the template could be used to identify which context the template belongs to and then have some sort of CLI switch to turn on contexts to reconcile.

Is there a better workaround? I thought maybe I could define a list of files within the ignore template and have the template loop through all the files with similar logic as the example mentioned in #2888 but I'm not sure if that's possible.

[Lockszmith-GH]

Specifically for bitwarden, 'logging in' is determined by an environment variable, so maybe one option would be to populate that environment variable effectivly. But I'm not suggesting this based on expereince.

If the above isn't feasable, one option I can suggest is separating the secret's based chezmoi configuration separate.
Similar to the layered approach I use to keep externals separate from the state I manage on my own.
See this and this discussion for more details.

[halostatue]

I came across issue #2888 and it seems like a similar pain point I'm having. I don't think it's a good idea to have an exposed session key in an environment variable all the time, particularly when it's rarely needed. I understand that there's no way for chezmoi to reconcile the source and target without using the password, but most of the time those files rarely change.

Unfortunately, chezmoi cannot know the difference without the authorization. Really, there are three options (I’m assuming bash/zsh here):

1. Use a wrapper function:

   chezmoi() (
     BW_SESSION="$(bw unlock --raw)" command chezmoi "$@"
   )

   This function is safe for two reasons:

   1. It sets BW_SESSION only for the run of command chezmoi (this prevents a loop).
   2. It runs in a sub shell (using fun() () instead of fun() {}).

   You may want to change it so that it only does the unlock when required, but that’s too detailed for a discussion in a shell I don’t run.

2. Use the new bitwarden secrets CLI, if you are an organization owner. Support for this hasn’t yet been released in chezmoi, but will be soon.

3. Use rbw and the associated rbw* template functions, which uses an agent model to hold access without exposing a short-lived BW_SESSION environment variable. The agent runs by default for one hour (3600 seconds), but this is configurable.

We would also welcome a PR contribution to add bw unlock --raw if BW_SESSION is unset, in the same way that the 1Password template functions do (see onepasswordGetOrRefreshSessionToken in internal/cmd/onepasswordtemplatefuncs.go), since bw get also accepts --session TOKEN from the command-line the same way that op does for 1Password.

This is not necessary with 1Password 8 & 1Password CLI 2 on a system with biometric authentication enabled for CLI access. I do not see similar options for either Bitwarden desktop or CLI.

[comminutus]

@halostatue I realize chezmoi can't compute the difference in templates which contain references to a password manager without authorization, but I don't think it should be trying to compute the difference on each invocation of verify, status, apply etc.

From a security perspective, it'd be better to compute differences in these kinds of templates only when the user specifically requests to do so, or at least have the option of turning this behavior on and off. The problem is with unauthorized access to the machine. When unauthorized access to the machine occurs, without using chezmoi, at most the private key files are exposed. With chezmoi, not only are the private key files exposed, but an open door into the entire password manager and all of its passwords. I would much rather give up a private key file since these are typically encrypted with a password anyway (with often the password stored in the password manager) than access to my entire password manager.

I think @Lockszmith-GH 's approach to layering works well for this, but as a chezmoi newbie setting up that kind of structure is daunting. I'm willing to give it a shot, but it's a bit like bringing a tank to a knife fight since I'm not an organization, just an individual who doesn't want to reconcile differences in secrets every time I use chezmoi. If there was a built-in way to manage contexts/namespaces, and selectively turn those on and off, it'd simplify the process. I don't think I'm alone in this problem.

I realize this is asking a lot though!

[Lockszmith-GH]

It just seems complicated.

I adopted the layered approach for performance when working with externals, which in a way, is exactly what you're dealing with. This was twpayne's idea, and it worked like a charm.

The cost was breaking the caching mechanism into separate 'packages'.

For myself, it was an acceptable cost.

Only after I had that, I then adopted it to an "organizational" solution, seeing the potential.

I'll update here in a bit with a template of a single repo with a layered implementation for externals.

Chezmoi is so flexible that you can practically have multiple secondary layers, as long as you can write a script that triggers the update when needed.

[Lockszmith-GH]

Actually, the original #2375 thread contains everything you need.

[halostatue]

@halostatue I realize chezmoi can't compute the difference in templates which contain references to a password manager without authorization, but I don't think it should be trying to compute the difference on each invocation of verify, status, apply etc.

chezmoi must compute that there is a difference between all files in its source state and the target state for most of the stated commands to work. chezmoi status could cheat and pretend that any .tmpl is modified, but that would also make it fairly useless as a command (IMO), if you have more than a few template files.

That is, computing that difference is the entire point of what chezmoi does.

From a security perspective, it'd be better to compute differences in these kinds of templates only when the user specifically requests to do so, or at least have the option of turning this behavior on and off. The problem is with unauthorized access to the machine. When unauthorized access to the machine occurs, without using chezmoi, at most the private key files are exposed. With chezmoi, not only are the private key files exposed, but an open door into the entire password manager and all of its passwords. I would much rather give up a private key file since these are typically encrypted with a password anyway (with often the password stored in the password manager) than access to my entire password manager.

Your threat model is wrong. If someone has unauthorized access to your machine, then they can use bw or rbw far more easily than they can use chezmoi to get access to the entire password manager contents. I provided you three options for improved (more easily locked down) access to BitWarden passwords, and rbw has a security-with-convenience (one hour session expiration by default), which is the opposite of the official bw tool (session is valid until invalidated with lock).

If you’re that worried about unauthorized access to your machine, you probably shouldn't have a password manager on your system at all, and should be typing your passwords &c. manually by reading them off your phone.

If you’re doing a lot with chezmoi and are using rbw:

$ rbw unlock
# perform unlock
$ chezmoi status
…
$ chezmoi merge foo
…
$ chezmoi apply
$ rbw lock

The first step isn’t necessary because both bw and rbw will attempt to perform an unlock automatically on the first get, and if you set rbw configuration short enough, you probably don't need to worry about that.

The 1Password CLI has better handling of its session tokens (30 minute expiry) and can also use 1Password 8 as an agent daemon (10 minute authorization expiry) where the lock status is shared between the desktop app and the 1Password CLI.

I think @Lockszmith-GH 's approach to layering works well for this, but as a chezmoi newbie setting up that kind of structure is daunting. I'm willing to give it a shot, but it's a bit like bringing a tank to a knife fight since I'm not an organization, just an individual who doesn't want to reconcile differences in secrets every time I use chezmoi. If there was a built-in way to manage contexts/namespaces, and selectively turn those on and off, it'd simplify the process. I don't think I'm alone in this problem.

There is no concept of 'context' or 'namespace' in chezmoi, and based on previous discussions, it is highly unlikely that they will be introduced for any reason. What's important to realize is that once you have a single run_ script or a single .tmpl, you no longer have perfect predictability on what the result of chezmoi apply will be, because you're making changes based on external data. It is not possible to perform static analysis on .tmpl files, and it is not possible to know whether there are changes to the output without executing those, which may require access to your password manager.

The only way to namespace is through the more complex mechanisms that @Lockszmith-GH has documented by using multiple state files and paths. I'm not sure whether we would want to adapt this into some sort of "advanced use cases" section of the documentation, but it would never be a mainstream recommendation for running chezmoi.

[halostatue]

TL;DR for the above:

1. The default BitWarden CLI is insecure by default. Use rbw or switch to a better password manager which has better security defaults.
2. chezmoi can only tell if there is a difference between a .tmpl and its target by executing the .tmpl.
3. chezmoi does not and likely will never have the concept of namespaces, as it is a very advanced use case with reasonable community documentation provided by @Lockszmith-GH.

[twpayne]

+1 on what @halostatue says.

The real fix here is to use a password manager with some kind of persistent session.

[Lockszmith-GH]

Totally agree with above. I don't advocate having contexts baked in chezmoi, the mechanism already exposes everything that is needed.

My solution is one that "works for me" and my team, and it is rather simple to implement in case you need it. (as you've probably noticed, I'm rather proud of it's simplicity and like sharing it), but it relies on chezmoi doing what it's designed to do reliably.

Reliablity is the key. Let's not bend it because I decided to track large github repos with chezmoi, or because I decided to use a secrets management that is very pedantic (I'm looking into utilizing bitwarden cli as well).

[comminutus]

chezmoi must compute that there is a difference between all files in its source state and the target state for most of the stated commands to work. chezmoi status could cheat and pretend that any .tmpl is modified, but that would also make it fairly useless as a command (IMO), if you have more than a few template files.

That is, computing that difference is the entire point of what chezmoi does.

That's exactly what I want it to do, except I don't want it to do this for secrets every time I run it since that requires unlocking something in some kind of a password manager, be it BitWarden, 1Password, etc.

If someone has unauthorized access to your machine, then they can use bw or rbw far more easily than they can use chezmoi to get access to the entire password manager contents.

If bw or rbw is in the locked state, or if using another password manager that doesn't have any valid session, then at most what is exposed is the private key files themselves. Most of my dotfiles are not secrets, only about 5% of them are. However, in order to use chezmoi for the 95% of the dotfiles, I have to unlock a password manager (be it 1Password, BitWarden, etc). Any unauthorized access to the machine with a valid session token exposes the entire password database. It'd be easier just to not unlock the password manager for the 95% of the dotfiles, and if a change is required to the other 5% then unlock the password manager, perform the update, and re-lock it.

The only way to namespace is through the more complex mechanisms that @Lockszmith-GH has documented by using multiple state files and paths. I'm not sure whether we would want to adapt this into some sort of "advanced use cases" section of the documentation, but it would never be a mainstream recommendation for running chezmoi.

I guess this is really the only way it can be done with the present state of chezmoi. I'll try to implement this.

[detly]

I was referring to @comminutus' change of heart about storing encrypted secrets. Both options seem to me to have drawbacks:

• Using password manager integration means having to enter credentials for most Chezmoi operations every time, so even though secrets might have the least frequent changes (eg. of the order of multiple years in my case) they have a kind of outsized impact on useability.

• Using encryption means storing secrets in a git repository; even a private repo can't really be assumed to be completely secret, and so it comes down to whether the encrypted secret is safe in this situation eg. against brute forcing, as mentioned. (A more minor point is that it also means installation and management of more software eg. age or out-of-band configuration eg. private keys, recipients; which are the kind of chores I'm hoping to reduce.)

Anyway, this is not a major issue for me, so far Chezmoi has happily dealt with 99% of everything I've pointed it at. Right now I am leaving secrets ignored by Chezmoi and copying them manually as needed, which is what I had to do before. I would just like to get a better understanding of any implications of the options you suggested and found this discussion.

[twpayne]

• Using password manager integration means having to enter credentials for most Chezmoi operations every time

This is true, and this problem is also alleviated by having a password manager that reduces the effort of entering your credentials.

Can you configure your password manager to use touch authentication instead of requiring you to type your password?

• Using encryption means storing secrets in a git repository; even a private repo can't really be assumed to be completely secret, and so it comes down to whether the encrypted secret is safe in this situation eg. against brute forcing, as mentioned.

Yes, you're right. chezmoi defers encryption to GPG and age, which I hope offer good encryption. Ultimately, though, you have to decide where and what you trust. There's always https://xkcd.com/538/.

• A more minor point is that it also means installation and management of more software eg. age

chezmoi builds age into its binary, and Go's built in supply chain security should allow you to verify the code that you run.

Hope this helps. If there's attack vectors that we've missed, please do share them.

[detly]

Would it be more appropriate/useful to spin this off into a separate discussion topic?

[comminutus]

@detly I don't store credentials in Git for dotfiles (gpg keys, ssh keys, etc). I think this is best done with a password manager. I use chezmoi's templating in combination with a password manager plugin for chezmoi to extract the secret from the password manager when necessary and apply it to the dotfile locally. The only thing inside of Git is the template.

I further get chezmoi to ignore my templated secret files unless I trigger a specific condition (i.e. setting a BW_SESSION environmenet variable. Most password managers have a way of avoiding logging in more than once on the same machine with their CLIs.

[detly]

@comminutus Okay, that's interesting to know. Thanks for following up.

I use Bitwarden, and while I'm aware that I can keep a session "alive" to avoid logging in, I often don't keep terminals open once I'm done with short-lived tasks. So I think the conditional-ignore approach suits me better.

@twpayne IIRC the built-in version of age does not support passphrase based decryption, only recipient based, so I'd need to update and re-encrypt files on existing environments in order to initialise a new environment. Installing age separately is not hard and would solve that, I'm just trying to figure out what all the pros and cons are so I don't shoot myself in the foot later on by locking myself out somehow.

Thank you both for your answers!

[twpayne]

Another way to achieve the goal of excluding files with secrets from chezmoi except when explicitly wanted is to use a .chezmoiignore file and an environment variable.

In your .chezmoiignore file put something like:

{{ if (eq (env "CHEZMOI_SECRETS") "0") }}
.ssh/id_rsa
{{ end }}

Then, if you run chezmoi with the environment variable CHEZMOI_SECRETS set 0 then chezmoi will ignore .ssh/id_rsa. If you set CHEZMOI_SECRETS to 1 (or anything else) then chezmoi will include .ssh/id_rsa.

You'll of course need to maintain the list of files containing secrets yourself.

[comminutus]

Great idea! Since all of this is really centering around the BW_SESSION env variable, why not just make sure it's unset any time bw lock is called? This really should be done inside the bw CLI, strange they keep it around.

To monkey patch it I did the following and just got rid of czunlock/czlock:

bw () {
    local bitwarden_user=<your email>

    if [ "$1" = "lock" ]; then
        unset BW_SESSION
    elif [ "$1" = "l" ]; then
        shift
        export BW_SESSION=$(command bw login $bitwarden_user --raw "$@")
    elif [ "$1" = "u" ]; then
        shift
        export BW_SESSION=$(command bw unlock --raw "$@")
    else
        command bw "$@"
    fi
}

Along with the .chezmoiignore file you provided, this works like a charm! Usage is as simple as bw u; <enter password> && chezmoi {status, verify, apply}; bw lock

[Lockszmith-GH]

I like this very much, I'll adopt this as well.

[halostatue]

Great idea! Since all of this is really centering around the BW_SESSION env variable, why not just make sure it's unset any time bw lock is called? This really should be done inside the bw CLI, strange they keep it around.

bw is a subprocess and does nothing with BW_SESSION except look for it, unfortunately, and they don’t provide shell wrappers the way that you have written. What is bizarre to me — and if I used Bitwarden, I would not use bw — is that there is no expiry at all for a generated session token. doy/rbw has better security defaults and is more usable overall because it does not depend on an environment variable. (doy/rbw does one thing worse than op for 1Password, which is that it authorizes all sessions for the daemon whereas 1Password only authorizes a particular terminal session; I have to reauthenticate in different windows/tabs. This sort of security is provided by accident with bw, but only because environment variables do not persist between terminal tabs or windows.)

One suggestion for your wrapper script: your session token is still valid, even though you remove it from your environment variables with unset. Do unset BW_SESSION && command bw lock for that case.

[comminutus]

Since I don't have any need for the output of bw login or bw unlock other than the "raw" form to capture the BW_SESSION, I do this now:

bw () {
    local bitwarden_user=<your BitWarden email>

    if [ "$1" = "l"  ] || [ "$1" = "lock" ] ; then
        unset BW_SESSION
        shift
        command bw lock "$@"
    elif [ "$1" = "li" ] || [ "$1" = "login" ]; then
        shift
        export BW_SESSION=$(command bw login $bitwarden_user --raw "$@")
    elif [ "$1" == "unlock" ] || [ "$1" = "u" ]; then
        shift
        export BW_SESSION=$(command bw unlock --raw "$@")
    else
        command bw "$@"
    fi
}

This overrides the default login and lock commands to always set/unset the BW_SESSION variable in case I accidentally use bw lock instead of bw l etc.

[Lockszmith-GH]

BTW, instead of shift and then "${@}" - you can just use: "${@:2}"