-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prefer FQDN for minion id only by default (Proposal) #48629
Comments
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? |
Historical context: every time we've changed the algorithm for determining minion_id, it has resulted in a world of pain. |
Why not to leave the default behavior as is but make an optional way to determine the personal order as a |
@gtmanfred, I am using Increasing security requires sending the public key of the minion via a second channel, right? |
@cro, I am aware of the many code changes in generating minion_id. Using the FQDN seems ‘safer’ than the hostname; what do you think of an option to mask a specific domain, like |
@DmitryKuzmenko, I like the idea of specifying a closed dictionary |
@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. |
@Karunamon, could you give more detail or an example of your use case? |
From all comments so far, I understand that FQDN is more secure/reliable than hostname. |
Closed this because continued as PR #49213 |
@Karunamon, do I understand you correctly that you want to black list and white list domains?
|
@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 :) |
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
andminion_id_prefer_FQDN = False
.Implementation ideas
I think there are 3 changes required.
which, depending on the value of
minion_id_prefer_FQDN
, would then becomeThe test case salt.tests.unit.utils.test_network.test_generate_minion_id_platform_fqdn(self) would need access to the new variable.
Documentation
E.g. the minion config file:
The text was updated successfully, but these errors were encountered: