The more I think about it, the more I convince myself that an USB key
(preferably connected to the internal USB connector) could be quite a
good compromise: cannot be stolen too easily (requires opening the
chassis), can be installed w/o requiring special skills, is cheap, and
stores "more than enough" :)
Now I only have to figure out how to reliably detect its presence during
install, then it's just matter of copying files.
Even better could be a "virtual key" connected via IPMI storage when
needed (even if data gets transferred in cleartext, it's over a "secured
network": only a fool would expose IPMI interface to unsecure networks!)...
Il 07/07/2022 08:55, Andrew Ruthven ha scritto:
Hey,
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.
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.
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.
We do in some cases generate passwords (root and encrypted filesystems)
during build and have those emailled with GPG encryption to the relevant
parties.
Cheers,
Andrew
On Thu, 2022-07-07 at 08:35 +0200, Diego Zuccato wrote:
Hi Andrew.
That's an option, but is seems less secure: while PXE net have to be
quite "locked down", NFS could potentially be exposed on a "public"
network (say to handle reinstalls on many networks with a single server).
If only machines had an "attestation key" by default... Maybe an USB key
to insert in the machine being reinstalled... Possibly in an internal
slot... Uhm... Still brainstorming...
Tks,
Diego
Il 07/07/2022 08:22, Andrew Ruthven ha scritto:
Hey,
I'm not sure if this is preferred or not, but the approach I take is to
have a command we run first, that copies any required secrets (and will
generate SSH host keys and puppet certs if required first) into the NFS
root. A cron job runs every 15 minutes and cleans up any of those
secrets which are older than 2 hours (this could be much shorter).
Cheers,
Andrew
On Thu, 2022-07-07 at 08:12 +0200, Diego Zuccato wrote:
Hi all.
Is there a preferred way to pass a (different) secret to every host
being installed?
Something to implement a workflow like:
- admin asks Salt to (re)install a host
- salt handles shutdown and switch reconfiguration (OT)
- salt tells FAIserver to enable install of given host
- FAI generates the secret and passes it back to Salt (or Salt generates
the secret and passes it to FAI, as long there's a shared secret)
- the host boots via network and installs as usual, saving/using the
given secret
- FAI (or the reinstalled host) tells Salt reinstall is complete and
Salt "cleans up" (reconfig switches & so on) (OT)
The only "solution" I could find is to save the secret in
/srv/tftp/fai/pxelinux.cfg/C0A8xxyy in append line, like FAI_FLAGS,
FAI_CONFIG_SRC and FAI_ACTION, but since append line can be at most 255
chars there's not much space... I's good just for very small "secrets"
(that gets transferred in the clear, hence the need to reconfigure the
switches).
--
Andrew Ruthven, Wellington, New Zealand
and...@etc.gen.nz <mailto:and...@etc.gen.nz> |
Catalyst Cloud: | This space intentionally left blank
https://catalystcloud.nz <https://catalystcloud.nz> |
--
Andrew Ruthven, Wellington, New Zealand
and...@etc.gen.nz |
Catalyst Cloud: | This space intentionally left blank
https://catalystcloud.nz |
--
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
