Re: Transient secrets
Diego Zuccato <[email protected]>
| Newsgroups | gmane.linux.debian.fai |
|---|---|
| Message-ID | <[email protected]> |
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 >>> [email protected] <mailto:[email protected]> | >>> Catalyst Cloud: | This space intentionally left blank >>> https://catalystcloud.nz <https://catalystcloud.nz> | >>> >> > > -- > > Andrew Ruthven, Wellington, New Zealand > [email protected] | > 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