Re: FAI + SaltStack anybody?

Il 06/10/2023 10:36, Sinh Lam ha scritto:
> Reading through your original post - I think there might be some 
> confusion as to what SaltStack does and what FAI does (if not, I 
> apologize).  SaltStack is a configuration management tool that is 
> normally used to ensure the target minion's configuration is exactly as 
> it should, while FAI is a provisioning tool that essentially builds the 
> server that SaltStack is used to manage.

No need to apologize even if I already knew the difference between FAI 
and Salt  :)

> 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.

> I do not believe that salt can do the actual installation of the 
> server’s OS because there’s no minion running to begin with.  You should 
> really leave that to FAI.

Yes, sure. Other tools (like xCat) try to do both and are IMVHO way less 
versatile.

>  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. [*]

> 2) issue a call to the salt master to accept the new minion when it is 
> registered during fai.  This involves you knowing the minion id/name of 
> the key.

That's what I'd like to make FAI do. If only there was a 'hook' system 
on FAI server, triggering scripts at the different stages... The nearest 
thing I could think of is a custom fai-monitor but it seems quite unsafe :(

> This is how I’m planning on using SaltStack with FAI -
> I have a dedicated network that is tightly controlled so to that point I 
> know what connects to it and I know why those servers are connected to 
> that particular network.  In essence, I trust this particular network.  
> Because of this, I have auto-accept turned on my salt master.

Can't do that: my networks are often exposed. The alternative would mean 
having to dynamically reconfigure switches to move ports to different 
VLANs... Quite a big can of worms on its own :(

> I have FAI install the base os on the server, toward the end of the 
> process, a couple things will happen:
> * a script will be used to auto-register this server with our CMDB
> * a script will be used to enroll this minion with the salt-master and 
> set the minion_id (if needed).

How does your script authenticate the requests? Or are you just relying 
on the "secured network" to bypass authentication?

[...]
> That’s it.  FAI does the OS (and handles the registering of the server 
> with our CMDB and the minion with the master), and salt stack takes care 
> of the configuration of the server.

That's the desiderable outcome :)

> The glue I believe you’re talking about is a source of truth to populate 
> pillar data and grains so your salt states can actually do something 
> useful.

No, that's already taken care of :)

> And MAC addresses can be spoofed quite easily, so you really shouldn’t 
> rely on that as your ‘root of trust’.  I deal with a lot of VMs and each 
> one of those VMs I can easily specify whatever MAC address I want (you 
> really shouldn’t).  But spoofing a MAC while it’s in the early parts of 
> pxe/net boot process is harder (if not impossible), you still shouldn’t 
> use it as the ‘root of trust’.

Yup, I know. Already did it in DOS :)
But stronger authentication either requires TPM or interaction.

-- 
Diego Zuccato
DIFA - Dip. di Fisica e Astronomia
Servizi Informatici
Alma Mater Studiorum - Università di Bologna
V.le Berti-Pichat 6/2 - 40127 Bologna - Italy
tel.: +39 051 20 95786