FAQ
Hi all,


I will start by explaining my scenario/use case, then will expose some
ideas that I had to accomplish what I need and then, finally, ask for
directions! :)


Ok, so I have several costumers that I would like to manage through
SaltStack. All of them are on AWS and most are using auto-scale so machines
are ephemeral and have the habit of vanish and appear without any human
interaction.

I don't want to manage the actual configuration of AWS through Salt. Only
the OS on the EC2 instances of my costumers (So i think Salt-Cloud is off).

I want to have all Salt code for all my costumers on a single code base and
split it by environments configured on the master (oh, and I mentioned that
I would like to have a single server running the salt-master(s) sitting on
my AWS account and have all the minions on the costumers accounts speaking
to it? :P).

The thing is... I *can't* on any circumstances have the
code/settings/variables of one costumer being set/fetch by another costumer.

How can I enforce that costumer A will not be able to setup a rogue server
pretending to be costumer B and have access to costumer B states and
variables?


Some things that I already know is that I can target minions by grains that
I can generate from Tags on the EC2 (so... being ephemeral is not a
problem) and that is possible to allow cross-account access to services
inside AWS.


Now... the Ideas! :P

I thought that I could setup on my account (actually on the same box as the
salt-master) one salt-syndic for every costumer listening on a specific
port and allow the access from that costumer to that specific port. But
this will only help me If I can restrict all the states that will be passed
to the minions connected on that syndic to the ones on a pre-configured
environment option.

As far as I found on the internet, the syndic doesn't have this
configuration option. :(


Another Idea would be that for every client I would spin up another
salt-master process, also listening on a specific port but with it's config
file setting the file_roots option only to the specific folder of that
costumer environment.

I could maybe configure this salt "lesser" masters from another master...


Well... this is my use case/problem... Does you guys have any pointers,
opinions URLs, voodoo settings, etc... that could help me?


Thanks a lot! :)


--
Leon

--
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

  • Colton Myers at Nov 17, 2014 at 11:55 pm
    Hey Leon,

    Sorry for the late reply, I'm going through old unanswered threads.

    There are some considerations to make here.

    There is no mechanism by which files on a master-of-masters are synced down to the syndic-masters. This means that you must either use GitFS, or sync those files somehow (you can use a minion on the syndic-masters that connects to the master-of-masters and use a file.recurse state to sync those files, for example).

    As it happens, this could be advantageous to you. The fileserver has no access control -- all minions can request any file on the fileserver. However, if you have a syndic for each customer, it means that that syndic's minions will only be able to access the files on that syndic. So that solves your access control problem. You could easily set up a separate git server for each customer's data and set up each syndic with GitFS and the git repo for that customer.

    Without the syndic architecture, you must use Pillar for any data that needs to be accessible only by a subset of minions. Pillar is the only way to keep data secure to a subset of minions.

    Hope that helps!

    --
    Colton Myers
    Platform Engineer, SaltStack
    @basepi on Github/Twitter/IRC
    On Oct 28, 2014, at 8:53 PM, Leon Waldman wrote:

    Hi all,


    I will start by explaining my scenario/use case, then will expose some ideas that I had to accomplish what I need and then, finally, ask for directions! :)


    Ok, so I have several costumers that I would like to manage through SaltStack. All of them are on AWS and most are using auto-scale so machines are ephemeral and have the habit of vanish and appear without any human interaction.

    I don't want to manage the actual configuration of AWS through Salt. Only the OS on the EC2 instances of my costumers (So i think Salt-Cloud is off).

    I want to have all Salt code for all my costumers on a single code base and split it by environments configured on the master (oh, and I mentioned that I would like to have a single server running the salt-master(s) sitting on my AWS account and have all the minions on the costumers accounts speaking to it? :P).

    The thing is... I *can't* on any circumstances have the code/settings/variables of one costumer being set/fetch by another costumer.

    How can I enforce that costumer A will not be able to setup a rogue server pretending to be costumer B and have access to costumer B states and variables?


    Some things that I already know is that I can target minions by grains that I can generate from Tags on the EC2 (so... being ephemeral is not a problem) and that is possible to allow cross-account access to services inside AWS.


    Now... the Ideas! :P

    I thought that I could setup on my account (actually on the same box as the salt-master) one salt-syndic for every costumer listening on a specific port and allow the access from that costumer to that specific port. But this will only help me If I can restrict all the states that will be passed to the minions connected on that syndic to the ones on a pre-configured environment option.

    As far as I found on the internet, the syndic doesn't have this configuration option. :(


    Another Idea would be that for every client I would spin up another salt-master process, also listening on a specific port but with it's config file setting the file_roots option only to the specific folder of that costumer environment.

    I could maybe configure this salt "lesser" masters from another master...


    Well... this is my use case/problem... Does you guys have any pointers, opinions URLs, voodoo settings, etc... that could help me?


    Thanks a lot! :)


    --
    Leon

    --
    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 <https://groups.google.com/d/optout>.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupsalt-users @
postedOct 29, '14 at 2:53a
activeNov 17, '14 at 11:55p
posts2
users2

2 users in discussion

Colton Myers: 1 post Leon Waldman: 1 post

People

Translate

site design / logo © 2022 Grokbase