Best practice for password/secret in rules scripts and other text configuration files

Hi,
I have some text files that contains password/secret, below are two examples:

  1. To get status of all Things (and send offline notification) I need to call OH RESTful API with credential
  2. In some .things files I have password/secret to connect to things like iCloud and Tesla

I use Github to keep track of versions, and I’d very much like to find a way to avoid uploading those passwords to cloud, and I think it’s not the best practice to keep secrets in clear text. What is your approach to keep them out of the scripts?
Any suggestion is appreciated!

I think there is no way to encrypt the .rules or .things files as such. So the ‘solution’ is probably to prevent unauthorized access to those files by an appropriate authentication system e.g. for the SMB file sharing. And obviously accessing the OH UI via HTTPS rather than HTTP.

1 Like

There currently is no way built into OH to handle secrets. There is a PR to support that better but it’s not complete nor merged yet. I hope that the framework for that support will be in place by OH 4, but it’s mostly focused on certificates. I’ve not followed the issues/PRs for a week or so so it might have been merged.

For now, best practice is to not check anything into a public repository that includes passwords or other secrets.

1 Like

Ok, thanks for your replies! I have managed to find a workaround for rules by defining secrets in a separated properties file and add it to gitignore, I can then read property from rules file like following:

    if(username === null){
        val properties = new Properties()
        properties.load(new StringReader(Files.readString(Paths.get("/path/to/config.properties"))));
        username = properties.get("username")
        password = properties.get("password")
    }```

However this trick only works with rules, not things.

Alternatively, you can tell systemd through LoadCredential to make the contents of a file available in a secure manner inside the service. You can then ship those credentials out-of-band through ssh or whatever else your deployment tool supports.

1 Like