Auto Accept Keys on the Salt Master

written by Alan Cugler on 2024-04-09

Auto Authentication of Salt Minions on the Salt Master

When writing Infrastructure as Code and constructing CICD operations there is a bridge between planned execution tested in the CICD pipeline and implementation in production environments. For device and virtual device management with salt one of those bridges is salt minion instantiation. In this demonstration we are assuming the minion deployment and configuration are already handled, and instead working with the salt master to prepare it for receiving the authentication request from the minion(s).

Security Concerns

There are three main ways to automatically accept minion keys. Two of those ways are considered insecure and one is considered secure. This tutorial is demonstrating the two insecure methods. This does not mean these solutions can't be used in production environments. It means a couple of environment expectations must be be met first for this to still be overall a "secure solution."

First, the salt master should not be accessible from the open internet and because of this none of the minions authenticating to the master should be coming from the open internet.
Second, an infrastructure team should have a whitelist or "Source of Truth" established for cross referencing salt minions against to ensure all that authenticated were expected to be present.

Method one: Master configuration for auto key acceptance

This method is accepting any new keys coming to the master as authentication requests.

Add to or make a new configuration file in the master.d directory.

# file: /etc/salt/master.d/auth.conf

auto_accept: True

Restart the salt-master to activate the new configuration.

$ systemctl restart salt-master

As a result you will see minions in the "Accepted Keys" category when checking salt-key rather than in the "Unaccepted Keys" category.

$ salt-key
Accepted Keys:
redhat7-minion-15
centos8-minion-16
ubuntu20-minion-1
ubuntu20-minion-2
ubuntu20-minion-3
Denied Keys:
Unaccepted Keys:
Rejected Keys:

NOTE

Another Master configuration option, open_mode: True, will accomplish the same outcome, but with additional side effects that mask an unhealthy environment. This will allow authentication even from minions that have duplicate minion IDs or duplicate minion keys. Generally, this solution should be rejected as you may have automation or HA/DR systems with critical flaws causing the duplication scenarios, and that's assuming no bad actors have slipped in by masquerading as another minion. It is better for the team to troubleshoot how the duplication events are happening and solving this problem rather than allowing blind overwriting.

Method two:

This is method is configuring an "auth event" Reactor to trigger minion key acceptance if the auth event data shows the data shorthand of pending as "pend". Reactors can be managed by the reactor runner module or by adding the reactor configuration to the master.d directory. We will demonstrate adding it to the master configuration as a concise demonstration.

Add to the reactors.conf or create one in the maqster.d directory.

# /etc/salt/master.d/reactors.conf

reactor:
  - 'salt/auth':
    - /srv/salt/reactor/auth_reactor.sls

Next add a reactor state file to be triggered by the reactor.

# /srv/salt/reactor/auth_reactor.sls

{% if data['act'] == 'pend' %}
Accept_new_minion:
  wheel.key.accept:
    - match: {{ data['id'] }}
{% endif %}```

Restart the salt-master to include the new reactor configuration. check for errors indicating a syntax error.
```console
$ systemctl restart salt-master
$ systemctl status salt-master

Finally, trigger a new minion to attempt authentication to the master.

# /etc/salt/minion.d/master.conf

id: new-minion
master: localhost # or the masters IP or hostname

$ systemctl restart salt-minion

As mentioned before, this should result with seeing a minion in the "Accepted Keys" category when checking salt-key rather than in the "Unaccepted Keys" category.

$ salt-key
Accepted Keys:
new-minion
Denied Keys:
Unaccepted Keys:
Rejected Keys:

Who We Are

Terminal Labs consultants are top of their field with flexibility for customers unique situations. We are the tip of the spear in Open-Salt consulting and integrations, and can handle any scale as much as Open-Salt can!

Author

Alan Cugler is a Solutions Architect with emphasis in Infrastructure as Code and CICD automation.