2

I'm interested in using SaltStack in stand-alone minion mode as a way of automating the various configs that I want to do for my personal dev environment. But as a good security conscious dev, what kind of attack vectors would I be opening myself up to here? Or are there any?

1

DNS

At least with the salt versions I tested (2014.1.13, shipping with Debian Jessie), the salt minion will still look for a salt master, regardless of whether file_client has been set to local or not. As a consequence, the security of your machine is highly dependent on the trustworthiness of your DNS.

By default, a minion accepts commands from any machine called salt in its namespace. So if your machine is named minion.example.com, and there is another machine named salt.example.com, the minion will happily accept commands from that master. The master has to confirm that the minion's key (with salt-key), but not the other way around. A laptop running a salt minion and being connected to an untrusted network is highly vulnerable.

I suggest adding something like 127.0.0.2 salt.example.com to your /etc/hosts file for that reason.

Configs Repository

This isn't specific to salt, but it may be worth mentioning: A big advantage of configuration management systems is to keep the configs in code which can be kept in a version control system. The security of all systems relies on the integrity of the respective repository. If there is the slightest doubt about whether someone could tinker with the code in the repo, I'd recommend to cryptographically sign all commits and to verify signatures before running the latest checkout. Git has the --sign option for committing. The last commit can be verified with git verify-commit HEAD.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.