Transient secrets
Diego Zuccato
diego.zuccato at unibo.it
Thu Jul 7 11:16:33 CEST 2022
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
>>> andrew at etc.gen.nz <mailto:andrew at etc.gen.nz> |
>>> Catalyst Cloud: | This space intentionally left blank
>>> https://catalystcloud.nz <https://catalystcloud.nz> |
>>>
>>
>
> --
>
> Andrew Ruthven, Wellington, New Zealand
> andrew at 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
More information about the linux-fai
mailing list