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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.