FAQ
All,

I understand what a "syndic" is used for ... but wanted to confirm in
reality how it operates, and if the following relationship and that my
expectations are inline with the methodology.

We have a relatively decent sized OpenStack cloud, with a number of
Domain/Projects (tenants). We do not allow access to VMs in a project via
Floating IPs for general access. We do not expose access to the VMs via a
private network. A projects VMs are completely isolated. Instead, we
instantiate a "bastion" host that has a Floating IP attached, and that's
the jump point to reach all of a projects resources. Projects to get
Floating IPs for "service endpoints", (e.g. whatever service their project
provides to the "outside world").

Since we don't have direct access to the internal VMs from outside of the
cloud (without altering/adding new plumbing...), I was thinking of using a
Syndic on the bastion host. In this case, the relationship would be like:

   outside cloud --> salt master
   outside cloud --> salt minions: talk to salt master above

   cloud edge --> "bastion" host: runs salt syndic, communicating with salt
master above

   inside cloud --> salt minions: connect to syndic on "bastion" host

In this case, I then (should) gain the ability to
query/command/control/etc. the minions inside the cloud, via the Syndic.

Any thoughts, gotchas, or considerations I should take in terms of doing
this? Thanks!

~~shane



--
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 Jul 11, 2014 at 9:56 pm
    That sounds like it should work.

    Just realize that the syndic is no more than an event forwarder (with a few
    helper features for job management). Basically, a syndic coexists with a
    master on a system, and connects that master to a higher-up
    master-of-masters. The master-of-masters can send jobs down through the
    syndic, to the minions which are controlled by the lower level master, and
    when those returns come back, the syndic forwards the return events up to
    the master-of-masters.

    Assuming the "bastion" host can reach both the master of masters, and the
    minions that it will be controlling, it should work. Just wanted to make
    sure you understood that that "bastion" host much have a master on it as
    well, as the syndic doesn't work solo.

    --
    Colton Myers

    On Wed, Jul 2, 2014 at 9:50 AM, Shane Gibson wrote:

    All,

    I understand what a "syndic" is used for ... but wanted to confirm in
    reality how it operates, and if the following relationship and that my
    expectations are inline with the methodology.

    We have a relatively decent sized OpenStack cloud, with a number of
    Domain/Projects (tenants). We do not allow access to VMs in a project via
    Floating IPs for general access. We do not expose access to the VMs via a
    private network. A projects VMs are completely isolated. Instead, we
    instantiate a "bastion" host that has a Floating IP attached, and that's
    the jump point to reach all of a projects resources. Projects to get
    Floating IPs for "service endpoints", (e.g. whatever service their project
    provides to the "outside world").

    Since we don't have direct access to the internal VMs from outside of the
    cloud (without altering/adding new plumbing...), I was thinking of using a
    Syndic on the bastion host. In this case, the relationship would be like:

    outside cloud --> salt master
    outside cloud --> salt minions: talk to salt master above

    cloud edge --> "bastion" host: runs salt syndic, communicating with salt
    master above

    inside cloud --> salt minions: connect to syndic on "bastion" host

    In this case, I then (should) gain the ability to
    query/command/control/etc. the minions inside the cloud, via the Syndic.

    Any thoughts, gotchas, or considerations I should take in terms of doing
    this? Thanks!

    ~~shane



    --
    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.
    --
    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.
  • Shane Gibson at Jul 11, 2014 at 10:03 pm

    On Fri, Jul 11, 2014 at 2:56 PM, Colton Myers wrote:

    That sounds like it should work.

    Just realize that the syndic is no more than an event forwarder (with a
    few helper features for job management). Basically, a syndic coexists with
    a master on a system, and connects that master to a higher-up
    master-of-masters. The master-of-masters can send jobs down through the
    syndic, to the minions which are controlled by the lower level master, and
    when those returns come back, the syndic forwards the return events up to
    the master-of-masters.

    Assuming the "bastion" host can reach both the master of masters, and the
    minions that it will be controlling, it should work. Just wanted to make
    sure you understood that that "bastion" host much have a master on it as
    well, as the syndic doesn't work solo.
    Thanks Colton. That tracks with my understanding too. The major drawback
    to this use is having to host a master with all of the associated content
    on it for the *entirety* of our salt master services. From a security
    perspective, this is an issue if we don't implicitly trust those users of
    the "bastion" node to with access to the salt enabled infrastructure.

    Unless I'm missing a feature set somewhere to provide "access" controls
    over what content/capabilities are available via those "bastion"
    Master/Syndic hosted services... ?

    ~~shane

    --
    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.
  • Colton Myers at Jul 18, 2014 at 9:09 pm
    Well, technically we don't have anything to sync the content from the
    master of masters down to the syndic masters. So minions at the bottom of
    the chain don't have access to anything that's not on the syndic master.
      Sounds like this missing feature might actually solve your issue, if I'm
    understanding correctly.

    --
    Colton Myers

    On Fri, Jul 11, 2014 at 4:03 PM, Shane Gibson wrote:
    On Fri, Jul 11, 2014 at 2:56 PM, Colton Myers wrote:

    That sounds like it should work.

    Just realize that the syndic is no more than an event forwarder (with a
    few helper features for job management). Basically, a syndic coexists with
    a master on a system, and connects that master to a higher-up
    master-of-masters. The master-of-masters can send jobs down through the
    syndic, to the minions which are controlled by the lower level master, and
    when those returns come back, the syndic forwards the return events up to
    the master-of-masters.

    Assuming the "bastion" host can reach both the master of masters, and the
    minions that it will be controlling, it should work. Just wanted to make
    sure you understood that that "bastion" host much have a master on it as
    well, as the syndic doesn't work solo.
    Thanks Colton. That tracks with my understanding too. The major drawback
    to this use is having to host a master with all of the associated content
    on it for the *entirety* of our salt master services. From a security
    perspective, this is an issue if we don't implicitly trust those users of
    the "bastion" node to with access to the salt enabled infrastructure.

    Unless I'm missing a feature set somewhere to provide "access" controls
    over what content/capabilities are available via those "bastion"
    Master/Syndic hosted services... ?

    ~~shane

    --
    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.
    --
    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 3:50p
activeJul 18, '14 at 9:09p
posts4
users2

2 users in discussion

Colton Myers: 2 posts Shane Gibson: 2 posts

People

Translate

site design / logo © 2022 Grokbase