What if Salt Minions no longer need to specify the IP or DNS address for the Master? Or even better: Master(s) can call minions. Of course, for the beginning, we would assume the network is trusted. But we should be able to add further security checks (keypairs etc).

Possible use cases:

  • Connect to a type of Master, not to a specific Master.
  • Connect to a less loaded Master.
  • Connect everything automatically on dynamic isolated networks


What are objectives:

  • Possibility to protect config-less Minion as much as possible. The Minion at best scenario, should be completely agnostic and have no prior pre-built knowledge about possible Masters (e.g. pub keys, fingerprints, passwords whatever else).
  • Untrusted networks should be addressed and taken to the account.

UPDATE what is now happily working already:

  • Entirely empty configuration to one Master. If there are several Masters, the closer wins (depends on packet speed) to be decided connect to, or not. With the empty configuration the Minion always sends a connect request at the moment. So the use case of "One Master at a trusted network for config-less Minions" is fully completed.
  • Minions can pre-define service. For example, Minion can now select which exactly Master needs to be connected to, because the Master can describe itself as being "SUSE Manager Master" or "Whatever You Need Master". So at this point while Minion has pre-built knowledge in it, the knowledge itself doesn't need to say the exact IP address or DNS name, but just describe what type of Master is expected (out of several, for example). So the use case of "Decide to connect to the Master based on its description (as a specific niche of the whole service)" is fully completed.


  • Select among all the Masters (currently first responded only).
  • "Police Mode" for completely config-less Minions (at least one trusted Master running required prior any Minion starts). Police Mode is a Salt Master verificator, which also is looking on another Masters on demand. Each Minion, when gets the list of all found Masters, also sends all of them to all Masters. So each Master gets the full list of known Masters at this point. Then each Master returns back either confirmation for the list of these Masters or inserts an alert that the certain IP is not trusted. In case at least one candidate of Masters returns such alert, Minion refuses to connect to anywhere, reporting in logs that certain IP is untrusted. Of course, this bypasses the entire autodiscovery, but this also says that the Network is not trusted and such incident should be removed first.

Looking for mad skills in:

Nothing? Add some keywords!

This project is part of:

Hack Week 16


  • over 1 year ago: Johannes Renner liked Salt Minion Discovery
  • over 1 year ago: bmaryniuk started Salt Minion Discovery
  • over 1 year ago: bmaryniuk originated Salt Minion Discovery
  • Show History


    • DZiolkowski
      over 1 year ago by DZiolkowski | Reply

      This is a bad idea, because it will leave potential for rogue machine takeover.

      Minions already discover Master on their own, the default Master is 'salt' in your domain name, so if you have control over DHCP and DNS, you already have such "discovery".

      Other than that, the usual use case is to configure Minion in post-install scripts. You need to install salt minion manually anyway, so you can also configure it.

      Or you can use salt-ssh to setup a new machine without having salt on them beforehand.

    Similar Projects

    This project is one of its kind!