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