> On Oct 6, 2023, at 10:59, Diego Zuccato <diego.zucc...@unibo.it> wrote:
>
> Il 06/10/2023 10:36, Sinh Lam ha scritto:
>> With the above said, I do not see what you mean there is a chicken and the
>> egg problem.
>
> To approve a minion key, Salt does have to trust the request is coming from
> the right minion, but it can't know till the key is approved.
Embed the Salt Master's public key in the FAI environment before the minion is
started. While the master won't have the minion key before it contacts it, you
can ensure the initial communication with the master is secured and the master
is properly identified. The keys themselves are generated by `salt-key
--gen-keys` on first run of the minion, if they don't exist.
So, during the install, pre-generate the keys with `salt-key`. Just ensure the
target directory for the private key ends up in
`/etc/salt/pki/minion/minion.pem` and the public key in
`/etc/salt/pki/minion/minion.pub`. The master's key needs to be in
`/etc/salt/pki/minion/minion_master.pub`.
With that, on the salt-master, either autoaccept, or find a way to place the
minion's public key in `/etc/salt/pki/master/minions/<minion-id>` and that will
bypass the key acceptance entirely. Keys, inside of salt, are just managing
where the file sits under the various minion directories in
`/etc/salt/pki/master/` after all.
>> Your concern was how to move the minion around servers that are getting
>> provisioned/re-provisioned so you don’t have to approve the minion each time
>> and I’m sure there’s a couple of ways to do this but right now I see two :
>> 1) turn on auto-accept - you don’t have to worry about approving any minions
>> because they’ll be auto-approved
>
> Can't do that on public networks. [*]
Don't have to do it if you set the master's public key, and minion keys, before
the minion is started though. Then it's just having a single job starting after
FAI's reboot, and doing `salt-call state.highstate` on first boot.
