On 2013-04-25 at 12:19 -0400, Will Dennis wrote: > Intrigued... I'd like to hear a (reasoned) argument against using Salt, > especially for those of us on the cusp of rolling out a new config mgmt. > system...
Here's a slightly redacted version of an analysis I wrote on Jan 2nd for a different audience. ----------------------------8< cut here >8------------------------------ http://www.saltstack.org/ Overview: http://docs.saltstack.org/en/latest/topics/index.html License: Apache 2.0 Synopsis: system configuration management (a la Puppet) but using ZeroMQ as a messaging substrate to be able to scale up well. Written in Python. On top of the messaging, it adds remote execution and config management. Expectation is that configuration files will be kept in a VCS such as Git (so it's theoretically designed to work with that instead of fight it). salt '*' cmd.exec_code python 'import sys; print sys.version' salt -C 'G@os:Debian and webser* or E@db.*' test.ping Unlike Puppet's custom languages, configuration is (by default) YAML, with the existing Jinja2 templating system. So, probably fewer bugs. ;) Easy to use an arbitrary Python script as a source of configuration data. Supplies a file-server for the master nodes, distributing over ZeroMQ. Has hierarchical masters, so that you can scale by having an overall master which distributes to "Salt syndics" which then handle the clients (don't know if this is pure hierarchy (ie breakable) or a set of available servers). Uses pubkey crypto from client machines (minions) with the master collecting the pubkeys (not normally accepting "any key", good). There's the ability to let minions run peer commands, also disabled by default (good, since otherwise that's a fast compromise contagion vector). Unfortunately, the key management docs: http://docs.saltstack.org/en/latest/topics/configuration.html#key-management state that it's all AES keys, which is symmetric and if each minion really is getting an AES key from the master, that had better be a per-minion AES key. :/ http://docs.saltstack.org/en/latest/ref/configuration/master.html http://docs.saltstack.org/en/latest/ref/configuration/minion.html https://github.com/saltstack/salt A bit more reassuring is: https://github.com/saltstack/salt/blob/develop/salt/crypt.py which claims to be all of the crypto-level code, and shows stuff like `verify_master()`. Note though that their message encryption/decryption contains no replay protection. Each message has a random IV, and is sent as IV+AES_CBC(payload)+HMAC(the_preceding) And yes, the AES key for this message, plus the HMAC key, are supplied by the master, when the minion successfully authenticates. And yes, it looks as though each client gets the one AES key generated by the master on start-up [salt/master.py AESFuncs._auth()], and cached on disk on the minions, so it looks suspiciously as though a compromised machine can impersonate the master on the common message-bus. I'm hoping I'm wrong on that; it needs more time to investigate than I'm willing to give it now. ----------------------------8< cut here >8------------------------------ _______________________________________________ Discuss mailing list Discuss@lists.lopsa.org https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
