<html><head></head><body><div><br>Hey,</div><div><br></div><div>Yes, agreed, depends on the use case. For the gear I'm dealing with they're on physically very secure networks and NFS is firewalled off.</div><div><br></div><div>You could potentially have a kernel token as you suggest and then go to fetch the secrets from a HashiCorp Vault with an approval needing to be issued.</div><div><br></div><div>I know of someone who used to store GPG encrypted tar files in their FAI profile and you had to enter a GPG key during the build to decrypt them.</div><div><br></div><div>We do in some cases generate passwords (root and encrypted filesystems) during build and have those emailled with GPG encryption to the relevant parties.</div><div><br></div><div>Cheers,</div><div>Andrew</div><div><br></div><div>On Thu, 2022-07-07 at 08:35 +0200, Diego Zuccato wrote:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>Hi Andrew.<br></div><div><br></div><div>That's an option, but is seems less secure: while PXE net have to be <br></div><div>quite "locked down", NFS could potentially be exposed on a "public" <br></div><div>network (say to handle reinstalls on many networks with a single server).<br></div><div>If only machines had an "attestation key" by default... Maybe an USB key <br></div><div>to insert in the machine being reinstalled... Possibly in an internal <br></div><div>slot... Uhm... Still brainstorming...<br></div><div><br></div><div>Tks,<br></div><div> Diego<br></div><div><br></div><div><br></div><div>Il 07/07/2022 08:22, Andrew Ruthven ha scritto:<br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>Hey,<br></div><div><br></div><div>I'm not sure if this is preferred or not, but the approach I take is to <br></div><div>have a command we run first, that copies any required secrets (and will <br></div><div>generate SSH host keys and puppet certs if required first) into the NFS <br></div><div>root. A cron job runs every 15 minutes and cleans up any of those <br></div><div>secrets which are older than 2 hours (this could be much shorter).<br></div><div><br></div><div>Cheers,<br></div><div>Andrew<br></div><div><br></div><div>On Thu, 2022-07-07 at 08:12 +0200, Diego Zuccato wrote:<br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>Hi all.<br></div><div><br></div><div>Is there a preferred way to pass a (different) secret to every host<br></div><div>being installed?<br></div><div><br></div><div>Something to implement a workflow like:<br></div><div>- admin asks Salt to (re)install a host<br></div><div>- salt handles shutdown and switch reconfiguration (OT)<br></div><div>- salt tells FAIserver to enable install of given host<br></div><div>- FAI generates the secret and passes it back to Salt (or Salt generates<br></div><div>the secret and passes it to FAI, as long there's a shared secret)<br></div><div>- the host boots via network and installs as usual, saving/using the<br></div><div>given secret<br></div><div>- FAI (or the reinstalled host) tells Salt reinstall is complete and<br></div><div>Salt "cleans up" (reconfig switches & so on) (OT)<br></div><div><br></div><div>The only "solution" I could find is to save the secret in<br></div><div>/srv/tftp/fai/pxelinux.cfg/C0A8xxyy in append line, like FAI_FLAGS,<br></div><div>FAI_CONFIG_SRC and FAI_ACTION, but since append line can be at most 255<br></div><div>chars there's not much space... I's good just for very small "secrets"<br></div><div>(that gets transferred in the clear, hence the need to reconfigure the<br></div><div>switches).<br></div><div><br></div></blockquote><div><br></div><div>-- <br></div><div><br></div><div>Andrew Ruthven, Wellington, New Zealand<br></div><div><a href="mailto:andrew@etc.gen.nz">andrew@etc.gen.nz</a> |<br></div><div>Catalyst Cloud: | This space intentionally left blank<br></div><div> <a href="https://catalystcloud.nz">https://catalystcloud.nz</a> |<br></div><div><br></div></blockquote><div><br></div></blockquote><div><br></div><div><span><pre>-- <br></pre><pre>Andrew Ruthven, Wellington, New Zealand
andrew@etc.gen.nz |
Catalyst Cloud: | This space intentionally left blank
https://catalystcloud.nz |
</pre></span></div></body></html>