salt-master behind NAT

[Ming Fang]

We have a use case where we want our master to manage cloud based minions.
The master is behind a NAT and the minions will be on an external network.
The problem is the master to minion communication requirers the minion to initiate a connection to the master on its return port.
The NAT will prevent the connection unless we make network changes, which is hard to get pass our security team.

We can probably find a workaround, but out of curiosity, why was salt designed this way?
Can’t we just have the master connect to the minion and use that connection for two way traffic?
That would not only address my use case, but will also reduce the number of sockets open on the master.

[David Boucha]

Have you tried salt-ssh?

--
You received this message because you are subscribed to the Google Groups "Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

Dave Boucha  |  Sr. Engineer

Join us at SaltConf, Jan. 28-30, 2014 in Salt Lake City. www.saltconf.com

5272 South College Drive, Suite 301 | Murray, UT 84123
office 801-305-3563
da...@saltstack.com | www.saltstack.com

[Ming Fang]

Yes. I use salt-ssh to bootrap the remote minion. That works.

But once the minion starts up it will try to phone home to the master. That will not work when the master is behind NAT.

As a workaround I’m going try to put a syndic master on the cloud, in the same network as the minions, as a proxy.

If that doesn’t work then I will move the master to the cloud as a last resort.  Certainly not ideal because we operate on multiple clouds.

[Bowen]

Can’t we just have the master connect to the minion and use that connection for two way traffic?
That would not only address my use case, but will also reduce the number of sockets open on the master.

As David pointed out, salt-ssh is the way to go if you need the salt-master to establish the connection out to the minions (rather than the minions connecting back to the master). salt-ssh is still relatively new and there are a few limitations, so if you find that it's not going to cut it you may also consider creating an intermediate salt-master out in your external network using salt-syndic. This would at least allow you to lock down the inbound connections to a single source IP address, which I'm sure your security team would be more comfortable with.

One other option is a bit of a DIY approach that I've taken myself using SSH and reverse port forwarding. You could write a script (Fabric[2] provides a good framework) to SSH to your servers and reverse port forward (-R flag for openssh) ports 4505 and 4506 back to your salt-master. I've found this more flexible because I don't have to use passwordless SSH keys or hardcoded passwords in my /etc/salt/roster file and, as far as the minions concerned, you have the full use of 0MQ-based salt, and the list of minions can be pulled from an external source (such as LDAP).

Good luck.

-

Bowen

[1] http://docs.saltstack.com/ref/syndic.html

[2] http://docs.fabfile.org

[Corey Quinn]

To answer the question of why Salt was designed this way, it's generally easier to expose one server than "all of them" in most environments. You can also get fairly restrictive with ACLs.

[martin f krafft]

also sprach Corey Quinn <co...@sequestered.net> [2014-01-04 13:14 +1300]:

> To answer the question of why Salt was designed this way, it's
> generally easier to expose one server than "all of them" in most
> environments. You can also get fairly restrictive with ACLs.

It would, IMHO, be best if I could choose per-minion whether it will
contact the master, or whether it expects the master to establish
a link to the minion, and a way to set a default.

And then, everything should go via a single, long-lived connection,
instead of the control/data separation that we have come to loathe
from the days of FTP.

On my wishlist for Salt 1.0… that, and the ability to use
roster-type commandeering of the nodes, rather than pubsub, which
the clients can choose to ignore (e.g. because of network hiccoughs)
without the master knowing…

--
martin | http://madduck.net/ | http://two.sentenc.es/

half a bee, philosophically, must ipso facto half not be.
but half the bee has got to be, vis-a-vis its entity. you see?
but can a bee be said to be or not to be an entire bee,
when half the bee is not a bee, due to some ancient injury?
-- monty python

spamtraps: madduc...@madduck.net

[Mrten]

On 4-1-2014 1:35, martin f krafft wrote:

> On my wishlist for Salt 1.0… that, and the ability to use
> roster-type commandeering of the nodes, rather than pubsub, which
> the clients can choose to ignore (e.g. because of network hiccoughs)
> without the master knowing…

Ooh, I thought I was the only one running multiple highstates to get one
to stick across all minions.

Numerous are the times that I see a minion doing things that should have
been applied two or three highstate runs ago.

A thumbs up from me here!

M.

[martin f krafft]

also sprach Mrten <mrten+s...@ii.nl> [2014-01-05 09:44 +1300]:

> Numerous are the times that I see a minion doing things that should have
> been applied two or three highstate runs ago.

For your reference: https://github.com/saltstack/salt/issues/2361

--
martin | http://madduck.net/ | http://two.sentenc.es/

"how do you feel about women's rights?"
"i like either side of them."
-- groucho marx

spamtraps: madduc...@madduck.net