Prefer FQDN for minion id only by default (Proposal)

[marbx]

Proposal

The salt minion may lack an explicitly declared id.

Without id, salt/utils/network._generate_minion_id() prefers FQDN (fully qualified domain name) over hostname. The function uses a variety of sources for the minion id.

I would like to introduce a new setting minion_id_prefer_FQDN = True, which leaves all logic as is by default, and otherwise prefers hostname over FQDN.

My goal is that minions automatically adapt their id to changing hostnames by setting minion_id_caching = False and minion_id_prefer_FQDN = False.

Implementation ideas

I think there are 3 changes required.

1) FQDN is prefered currently by the order of various id sources:

    hosts = DistinctList().append(socket.getfqdn()).append(platform.node()).append(socket.gethostname())

which, depending on the value of minion_id_prefer_FQDN, would then become

     node, gethostname, getfqdn 

2) The test case salt.tests.unit.utils.test_network.test_generate_minion_id_platform_fqdn(self) would need access to the new variable.

3) Documentation E.g. the minion config file:

# Explicitly declare the id for this minion to use, if left commented the id
# will be the hostname as returned by the python call: socket.getfqdn()

[gtmanfred]

My biggest concern is that if the minion id changes with the hostname, then you are going to have problems with having to reaccept the key by the new name on the master, and any attempt to automate that feels like it is just going to cause security problems.

@saltstack/team-core anyone else have an opinion about this?

[cro]

Historical context: every time we've changed the algorithm for determining minion_id, it has resulted in a world of pain.

[DmitryKuzmenko]

Why not to leave the default behavior as is but make an optional way to determine the personal order as a list like it's done in /etc/nsswitch.conf? I mean instead of using minion_id_prefer_FQDN = True to use the list like minion_id_prefer = [node, gethostname, getfqdn, quote_of_the_day, fortune]. And make this lazy—wait for it—loadable! =)))

[marbx]

@gtmanfred, I am using auto_accept: True, and id changes are accepted too. This 'automation' was just configuration.

Increasing security requires sending the public key of the minion via a second channel, right?

[marbx]

@cro, I am aware of the many code changes in generating minion_id. I know that you have all the experience, where I only need to solve a problem.

Using the FQDN seems ‘safer’ than the hostname; what do you think of an option to mask a specific domain, like minion_id_supress_domain: foo.bar.com?

[marbx]

@DmitryKuzmenko, I like the idea of specifying a closed dictionary minion_id_prefer = [node, hostname, fqdn] instead of a Boolean.

[Karunamon]

@markuskramerIgitt Speaking purely as a feature request, this would be very helpful. In my environment, having salt.mydomain Just Work® on new minion installs without further configuration is the default use case. With this, we'd be able to blacklist a couple of internal subdomains whose new machines always wind up talking to our master due to human error.

[marbx]

@Karunamon, could you give more detail or an example of your use case?

[marbx]

From all comments so far, I understand that FQDN is more secure/reliable than hostname. You must no strip the domain, when the same hostname can appear in several domains.

[marbx]

Closed this because continued as PR https://github.com/saltstack/salt/pull/49213

[marbx]

@Karunamon, do I understand you correctly that you want to black list and white list domains? Example:

minion_white_list_domain: good1.bar, good2.bar, good3.bar
minion_black_list_domain: evil1.bar, evil2.bar, evil3.bar 

[Karunamon]

@markuskramerIgitt You've got it.

Though it appears I completely misunderstood the nature of this issue and the comment I was replying to. Lesson learned, stay the heck off of Github when ill :)