Security: open call for thoughts on securing WTF's config file

[senorprogrammer]

WTF's config.yml file is a plain text file stored in the user's home directory. Given the nature of many of the modules in WTF, that file could hold account information, passwords, URIs, and API keys for the user's critical systems.

This issue is a place to discuss the security of that file.

1. Does it need to be secured? Should we just trust the machine instead?
2. If it should, how so? What's least-friction for the user?

[Seanstoppable]

This is interesting. Definitely something to think about. A bit harder since we support multiple file systems, and

Something low effort would be just checking file permissions and making sure the file is not readable for anyone except the user (0600 on *nix filesystems), similar to how ssh keys fail.

For more security conscious people, we could also support this like a plugin. I've been looking at a program called 'chezmoi' for handling my dot files, largely because of secret management https://github.com/twpayne/chezmoi/blob/master/docs/HOWTO.md#Keep-data-private, and it's methodology seems somewhat appropriate here.
Since chezmoi is written in golang, we could probably even just use it as a library.

[senorprogrammer]

SSH keys are a good point. This file doesn't likely need to be more secure than anyone's private keys. I like the 0600 idea as a start.

[senorprogrammer]

#518 has been merged in. Ensures the default config is chmod 0600.

[senorprogrammer]

From a HN comment: "Without that you can't share your configs or have your config in your dotfiles-repository."

Not sure I buy the config sharing argument, but the dotfiles repo one is very valid.

[mide]

I would also like to see some concept of secrets management; I am not a huge fan of having my API keys just resident in a file on my computer.

Maybe if you could specify environment variables in the config, that way a user could use their own secrets management scheme.

...
    github:
      apiKey:
        env: GITHUB_API_KEY
      baseURL: ""
      enabled: true
      enableStatus: true
      position:
        top: 1
        left: 2
        height: 3
        width: 2
      refreshInterval: 300
...

And then they can invoke by doing something like:

GITHUB_API_KEY=$(cat /my/secret_file.txt) wtfutil

or

GITHUB_API_KEY=$(aws ssm get-parameter --name /util/wtfutil/github_api) wtfutil

or

GITHUB_API_KEY=$(op get item GitHub | jq '.details.fields[] | select(.designation=="api_key").value') wtfutil

Now, does it really matter? That means I'd still have my secret accessible at runtime. I'd have to have my AWS key and secret or whatever else, which would be no different from having in this file. Maybe flexibility is worthwhile for people.

[maweki]

Since it came up in the discussion on hacker news (https://news.ycombinator.com/item?id=20817101):

I have all my config files in a repository (https://github.com/maweki/dotfiles) that I bring out into the system using stow (https://www.gnu.org/software/stow/). I only copy a few password and key files manually to a new pc. All configuration is kept up-to-date through the stow-ed symlinks into the dotfiles repository. This way of handling it makes it impossible to, for example, use the github module as the api key needs to be in that file and I obviously don't want to push the key to my dotfiles repo.

I think a good way to handle this would be the way home-assistant does it (https://www.home-assistant.io/docs/configuration/secrets/) where you give secrets with a special prefix and they are loaded from a secrets file.

The secrets file can be protected separately using git-secret or any other option to protect/encrypt single files.

The goal would be to have no private information in the main configuration file so that it can be shared without modification.

[senorprogrammer]

Someone opened a CVE on the file perms: https://nvd.nist.gov/vuln/detail/CVE-2019-15716

Note that this issue is already fixed in v0.20.0, released last week.

[senorprogrammer]

After first pass, I like the look of how Hass is doing things. Supporting an external secrets.yml file could be a relatively straight-forward first step.

[senorprogrammer]

@mide Modules that take an apiKey currently support the use of env vars to set that value. Unfortunately the docs don't currently document this capability so to figure out what they need to be called, you'll need to look into each module's settings.go source.

Here's the GitHub source: https://github.com/wtfutil/wtf/blob/master/modules/github/settings.go#L37

That said, it would be preferable for the user to be able to define the name of their env var and tell WTF what it is, rather than how it is now.

[OJFord]

I like the idea of kubernetes-ish sub-keys as env above, since it allows other options:

module:
    secret1:
        env: MY_SECRET
    secret2:
        file: /keybase/team/myteam/module-secret2
    secret3:
        cmd: aws secretsmanager get-secret-value --secret-id=module-secret3
    secret4: hunter2

[senorprogrammer]

For API keys, all modules that take an API key setting also support setting that value via env var. The docs for all of them have now been updated to reflect this.

Examples:

• https://wtfutil.com/modules/github/
• https://wtfutil.com/modules/opsgenie/