Transient secrets

Andrew Ruthven andrew at etc.gen.nz
Thu Jul 7 08:55:09 CEST 2022


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
> > andrew at etc.gen.nz         |
> > Catalyst Cloud:           | This space intentionally left blank
> >   https://catalystcloud.nz |
> > 
> 

-- 
Andrew Ruthven, Wellington, New Zealand
andrew at etc.gen.nz |
Catalyst Cloud: | This space intentionally left blank
https://catalystcloud.nz |

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-koeln.de/pipermail/linux-fai/attachments/20220707/e280bc71/attachment-0001.html>


More information about the linux-fai mailing list