4 ms·
Regarding deploying servers that you don’t have access to, you could deploy them with a boot loader that netboots signed images, require a certain number of dev
by predakanga 7y ago
Regarding deploying servers that you don’t have access to, you could deploy them with a boot loader that netboots signed images, require a certain number of developers to sign each image.
I’ve considered something similar for deploying k8s workers - just a ramdisk that encrypts local storage with a random key, then requests admission to the cluster.
Troubleshooting is harder, but I can imagine a fault reporting component that anonymises error reports and uploads them to a public-visible tracker. If something looks like a hardware failure, take it out of the infra and boot a traditional OS to do some diagnostics.
- KaiserPro 7y ago> netboots signed images There is no safe way to do this. Netboot picks up the fastest dhcp/tftp server to reply. which means there is nothing to stop something booting a hypervisor, then booting your image.
- thenewnewguy 7y agoI think you missed a few words there: "with a boot loader that netboots signed images". They won't be relying on the BIOS netboot that picks up the first DHCP server, but rather a custom bootloader that will check the signature on the image before running it.
- KaiserPro 7y agoWhich you can't really trust for the same reason.
- thenewnewguy 7y agoWhy not? If you're writing the bootloader (or using one that's trustworthy and open source) and deploying it by yourselves then it should be relatively safe. An attacker would have to have physical access to the hardware, or some method of modifying the bootloader on disk.
- craftinator 7y agoUnfortunately, for this use case the attacker that users are worried about are also the ones that will be installing the bootloader on the server in the first place. I don't see, from a computer science point of view, a process for verification that can't be emulated by the system that runs it.