Secure deploy of keys

Robert Markula robert at markula.org
Thu Dec 15 18:53:16 CET 2022


Am 15.12.22 um 18:15 schrieb Toomas Tamm via linux-fai:
> This message was wrapped to be DMARC compliant. The actual message
> text is therefore in an attachment.
Hi Toom,

unforunately I can't quote you directly, but regarding a rogue attacker 
mimicking the MAC of an install client: You have to manually enable a 
FAI installation, otherwise the client cannot be installed:

fai-chboot -c DEFAULT client.example.com

Granted, with the right timing one could be faster with a rogue client 
than with the real client. But on the other hand, any client with access 
to the FAI NFS server can manually mount the NFSroot and obtain any 
secrets living on the NFS server via this method.

So keeping a secret on the NFSroot is not a viable solution. But there 
are possibilities to work around that. What has been discussed:

1. the secret is created on the install client during installation and 
transfered to another system in a secure way, e.g. via SSH
2. the secret is pulled from a third-party solution, which is outside 
the scope of FAI (e.g. via Salt, Cfengine or any other configuration 
management software). Authenticated registration of the install client 
to the configuration management software of your choice is the weakest 
link here [1]
3. using public key encryption (GPG, PKI, SSH) [2]
4. using a zero-trust-like approach to secrets like clevis/tang [3]

I have not looked into solutions like HashiCorp Vault, but maybe that 
can be cleverly integrated as well?

Kind regards,


Robert

[1] https://www.mail-archive.com/linux-fai%40uni-koeln.de/msg07955.html
[2] https://www.mail-archive.com/linux-fai%40uni-koeln.de/msg08003.html
[3] https://www.mail-archive.com/linux-fai%40uni-koeln.de/msg08005.html


More information about the linux-fai mailing list