FAQ
I'm wondering how other people have successfully used salt to manage hosts in their DMZ.

At first we were considering just opening up the ports but we have some concerns around this. We don't like that all of the states and files that are applied to a server are kept in /var/cache/salt for anyone to see. Also, any minion that has an accepted key could really call any state file from the master including any of what we have called "roles" and "packages". This seems less than ideal from a security standpoint.

I then was looking into having masterless minions in the DMZ. This seems pretty good except we lose some of the functionality of salt that I love so much, the ability to easily and quickly run commands or queries across all our severs from a single CLI. I could pair this with salt-ssh and run that from our existing master, this seems to get us close but we then have to remember that we have 2 different commands to use to manage the 2 sets of our minions.

The 3rd option, that I'm still trying to avoid, is creating a new master just for hosts in the DMZ. This could solve a lot of problems but means we have to now manage salt config files in 2 different places and run salt commands from 2 different masters. Not the end of the world but less than ideal.

I'm leaning towards local salt configs + salt-ssh but before I head down that road I wanted to get some input from people and see if maybe there's a better way to do this, possibly something that I have yet to consider.

Thanks,
Dan

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Viq at Jul 3, 2014 at 11:05 am

    On Thu, Jul 3, 2014 at 12:48 AM, Dan Finn wrote:
    I’m wondering how other people have successfully used salt to manage hosts
    in their DMZ.

    At first we were considering just opening up the ports but we have some
    concerns around this. We don’t like that all of the states and files that
    are applied to a server are kept in /var/cache/salt for anyone to see.
    Also, any minion that has an accepted key could really call any state file
    from the master including any of what we have called “roles” and “packages”.
    This seems less than ideal from a security standpoint.

    I then was looking into having masterless minions in the DMZ. This seems
    pretty good except we lose some of the functionality of salt that I love so
    much, the ability to easily and quickly run commands or queries across all
    our severs from a single CLI. I could pair this with salt-ssh and run that
    from our existing master, this seems to get us close but we then have to
    remember that we have 2 different commands to use to manage the 2 sets of
    our minions.

    The 3rd option, that I’m still trying to avoid, is creating a new master
    just for hosts in the DMZ. This could solve a lot of problems but means we
    have to now manage salt config files in 2 different places and run salt
    commands from 2 different masters. Not the end of the world but less than
    ideal.
    We went with this option. We have two masters, though currently have
    one set of states in git, which is replicated to both master servers.
    So it kind of avoids "a compromised server gains control of our whole
    infrastructure" but still all servers can get access to all states.
    Personally I would have preferred to use one master, but I guess I am
    less paranoid than others.
    And yeah, we keep sensitive data in pillars.
    I’m leaning towards local salt configs + salt-ssh but before I head down
    that road I wanted to get some input from people and see if maybe there’s a
    better way to do this, possibly something that I have yet to consider.
    --
    viq

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Crispee M at Jan 26, 2015 at 4:34 pm
    Good Morning!

    So, with the 3rd option. How would this be implemented?

    Here is an example of our infra:
    1. DMZ servers are accessible via jumpbox & potentially network traffic
    management point

    What we want to use this for:
    1. Building and Deploying webservers

    Thanks!
    Chris
    On Thursday, July 3, 2014 at 7:05:57 AM UTC-4, vic viq wrote:

    On Thu, Jul 3, 2014 at 12:48 AM, Dan Finn <df...@backcountry.com
    <javascript:>> wrote:
    I’m wondering how other people have successfully used salt to manage hosts
    in their DMZ.

    At first we were considering just opening up the ports but we have some
    concerns around this. We don’t like that all of the states and files that
    are applied to a server are kept in /var/cache/salt for anyone to see.
    Also, any minion that has an accepted key could really call any state file
    from the master including any of what we have called “roles” and
    “packages”.
    This seems less than ideal from a security standpoint.

    I then was looking into having masterless minions in the DMZ. This seems
    pretty good except we lose some of the functionality of salt that I love so
    much, the ability to easily and quickly run commands or queries across all
    our severs from a single CLI. I could pair this with salt-ssh and run that
    from our existing master, this seems to get us close but we then have to
    remember that we have 2 different commands to use to manage the 2 sets of
    our minions.

    The 3rd option, that I’m still trying to avoid, is creating a new master
    just for hosts in the DMZ. This could solve a lot of problems but means we
    have to now manage salt config files in 2 different places and run salt
    commands from 2 different masters. Not the end of the world but less than
    ideal.
    We went with this option. We have two masters, though currently have
    one set of states in git, which is replicated to both master servers.
    So it kind of avoids "a compromised server gains control of our whole
    infrastructure" but still all servers can get access to all states.
    Personally I would have preferred to use one master, but I guess I am
    less paranoid than others.
    And yeah, we keep sensitive data in pillars.
    I’m leaning towards local salt configs + salt-ssh but before I head down
    that road I wanted to get some input from people and see if maybe there’s a
    better way to do this, possibly something that I have yet to consider.
    --
    viq
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupsalt-users @
postedJul 2, '14 at 10:48p
activeJan 26, '15 at 4:34p
posts3
users3

3 users in discussion

Crispee M: 1 post Dan Finn: 1 post Viq: 1 post

People

Translate

site design / logo © 2022 Grokbase