Verify master pub key

[iamb]

Currently, minions will always accept a master pubkey at first connect (provided it verifies the master has the correct private). I'd like to have at least configurably a mode where minion will not accept an unknown master.

Possibly a new minion config param "trust_mode" or so -- "open" (like open_mode True) "store" (same as now, default?) "strict" (key must be known). If both open_mode and trust_mode...take the more restrictive is probably The Right Thing

Motivation would be running a system in an untrusted network (something like amazon ec2). Getting master pub key in place would probably be outside the scope of salt though it would be possible to extend for minions something like what masters do to verify minion pubkeys...

• minion connects but doesn't know master
• wait, check for (local) acceptance of master key, wait, etc

Hopefully even re-use the 'retry' logic...haven't checked that yet

salt-key could be extended to "master" and "minion" modes for accepting master keys

I'm starting to work on this, comments, criticisms gladly taken

[SEJeff]

The ssh model seems like the path of least resistance.

When the minion first starts, have it connect to the master as specified by the hostname in it's configuration. When it initially authenticates, you can have it auto-accept that key, or do something like you do on the master with salt-key to "accept" the master's key. Then cache that key locally and if you ever see a different master key when reconnecting, complain loudly and barf all over the place... much like ssh does today with the default configuration :)

[iamb]

Exactly. Default behavior of ssh is like the method with salt-key...if unknown at first connect, verify the key (unless configured otherwise) then store it. I suppose "store" should be something more like "autostore" since a manually accepted key would obviously be stored too. Maybe config options "open" "autostore" "verify" "strict" would be more appropriate, with "verify" using the salt-key method (become default? this might change behavior unexpectedly for current users) and "strict" requiring a key already be stored. Even spilling that to master behavior might be useful...instead of just open_mode, modes "open" "verify" "strict" where "strict" might be useful for paranoid installations

Barfing loudly if the master key doesn't match the stored master key is already implemented and the behavior today. :)

[SEJeff]

The idea is good, would you be up for doing an implementation?

[iamb]

Yup, might take me a couple days for this one but I'm on it.

[thatch45]

thanks iamb, this is something I originally intended but it slipped through the cracks. we will need to add the commands to salt-key to manage the master public keys as well as adding info to the configuration files. Thanks!

[iamb]

Just checking in, lifely priorities have taken weight but I plan to get to this on the weekend.

[iamb]

I believe I have this pretty well implemented. It's in my fork, branch 'trust-mode'. I would appreciate any feedback, testing, whathaveyou before making a pull request. Happy to discuss anything in there.

[thatch45]

Awesome, I will take a look

[thatch45]

This is very extensive but I like consolidating the option into trust_mode.

Since so much of this happens in the security system I will have to go over it very closely. I will let you know. Thanks for this work, it looks good so far!

[iamb]

Thanks, I know it's pretty big. It just seemed the most sensible to consolidate all that stuff into one config option.

I did push a few more changes this morning, a couple just spacing and error message changes. There was one glaring bug though...in salt-key I was trying to automatically determine master/minion from the config file. Doesn't work since configs are read differently whether master or minion. The only realistic way I could see to do it is to add --master and --minion parameters to salt-key. Default is --master, so no change to current behavior if not specified.

[thatch45]

Sounds like a solid solution, I will look again.

I will be testing this soon

[thatch45]

Added in 0.10.3 via the master_finger option