Conversation
|
Azure Static Web Apps: Your stage site is ready! Visit it here: https://lemon-wave-085522403-317.westeurope.1.azurestaticapps.net |
|
I've added a helper service for stronger PCR binding when updates are disabled |
|
Azure Static Web Apps: Your stage site is ready! Visit it here: https://lemon-wave-085522403-317.westeurope.1.azurestaticapps.net |
Also added a more advanced setup that can do rebinding on updates. |
|
Azure Static Web Apps: Your stage site is ready! Visit it here: https://lemon-wave-085522403-317.westeurope.1.azurestaticapps.net |
What I found was |
|
Azure Static Web Apps: Your stage site is ready! Visit it here: https://lemon-wave-085522403-317.westeurope.1.azurestaticapps.net |
|
Azure Static Web Apps: Your stage site is ready! Visit it here: https://lemon-wave-085522403-317.westeurope.1.azurestaticapps.net |
|
Azure Static Web Apps: Your stage site is ready! Visit it here: https://lemon-wave-085522403-317.westeurope.1.azurestaticapps.net |
|
Azure Static Web Apps: Your stage site is ready! Visit it here: https://lemon-wave-085522403-317.westeurope.1.azurestaticapps.net |
|
Azure Static Web Apps: Your stage site is ready! Visit it here: https://lemon-wave-085522403-317.westeurope.1.azurestaticapps.net |
I think I now have a setup that should work, it's the last Butane example. One more reboot was needed after an update is booted because grub reads the GPT flags and takes a different code path to reduce the tries to 0. |
|
Azure Static Web Apps: Your stage site is ready! Visit it here: https://lemon-wave-085522403-317.westeurope.1.azurestaticapps.net |
|
Azure Static Web Apps: Your stage site is ready! Visit it here: https://lemon-wave-085522403-317.westeurope.1.azurestaticapps.net |
|
Azure Static Web Apps: Your stage site is ready! Visit it here: https://lemon-wave-085522403-317.westeurope.1.azurestaticapps.net |
| append: | ||
| - inline: | | ||
| insmod tpm | ||
| tpm_record_pcrs 8-9 |
There was a problem hiding this comment.
I think tpm_record_pcrs is not needed, but not really sure yet.
There was a problem hiding this comment.
Since it doesn't hurt I guess we could keep it but if it's a no-op we can also remove it again.
There was a problem hiding this comment.
i would remove this and make sure grub does the measuring by default. we don't want everyone to run a different configuration that we risk breaking
There was a problem hiding this comment.
I prepared a change here: flatcar/scripts#1861
| Example for TPM2-backed rootfs encryption with systemd-cryptenroll and stronger PCR binding (requires UEFI), with a added unbinding while the update reboot is pending (Butane YAML): | ||
|
|
||
| ```yaml | ||
| variant: flatcar |
There was a problem hiding this comment.
tested also on Hyper-V with TPM2 functionality, works as expected.
For binding a secret to the OS we need TPM PCRs that measure the kernel and boot configuration. Used for: flatcar/flatcar-website#317
|
By removing the PCR 5 binding the additional update reboot can be removed and I think this has no security implications. |
|
Azure Static Web Apps: Your stage site is ready! Visit it here: https://lemon-wave-085522403-317.westeurope.1.azurestaticapps.net |
For binding a secret to the OS we need TPM PCRs that measure the kernel and boot configuration (UEFI). Used for: flatcar/flatcar-website#317
For binding a secret to the OS we need TPM PCRs that measure the kernel and boot configuration (UEFI). Used for: flatcar/flatcar-website#317
|
Azure Static Web Apps: Your stage site is ready! Visit it here: https://lemon-wave-085522403-317.westeurope.1.azurestaticapps.net |
As documented in flatcar/flatcar-website#317 we can use PCR binding in Flatcar with some limitations and workarounds. I think we should be able to get rid of the first boot PCR difference by handling the first-boot flag detection in userspace and if we can guarantee that the outcome of setting the first boot or not is the same, i.e., we would have to always measure the effective Ignition config. For the rebinding on update the best bet we have is to create a Flatcar variant with sd-boot for signed PCR policies. Anyway, these are future topics and it's already good that we can make some encryption setups work.
As documented in flatcar/flatcar-website#317 we can use PCR binding in Flatcar with some limitations and workarounds. I think we should be able to get rid of the first boot PCR difference by handling the first-boot flag detection in userspace and if we can guarantee that the outcome of setting the first boot or not is the same, i.e., we would have to always measure the effective Ignition config. For the rebinding on update the best bet we have is to create a Flatcar variant with sd-boot for signed PCR policies. Anyway, these are future topics and it's already good that we can make some encryption setups work.
As documented in flatcar/flatcar-website#317 we can use PCR binding in Flatcar with some limitations and workarounds. I think we should be able to get rid of the first boot PCR difference by handling the first-boot flag detection in userspace and if we can guarantee that the outcome of setting the first boot or not is the same, i.e., we would have to always measure the effective Ignition config. For the rebinding on update the best bet we have is to create a Flatcar variant with sd-boot for signed PCR policies. Anyway, these are future topics and it's already good that we can make some encryption setups work.
As documented in flatcar/flatcar-website#317 we can use PCR binding in Flatcar with some limitations and workarounds. I think we should be able to get rid of the first boot PCR difference by handling the first-boot flag detection in userspace and if we can guarantee that the outcome of setting the first boot or not is the same, i.e., we would have to always measure the effective Ignition config. For the rebinding on update the best bet we have is to create a Flatcar variant with sd-boot for signed PCR policies. Anyway, these are future topics and it's already good that we can make some encryption setups work.
As documented in flatcar/flatcar-website#317 we can use PCR binding in Flatcar with some limitations and workarounds. I think we should be able to get rid of the first boot PCR difference by handling the first-boot flag detection in userspace and if we can guarantee that the outcome of setting the first boot or not is the same, i.e., we would have to always measure the effective Ignition config. For the rebinding on update the best bet we have is to create a Flatcar variant with sd-boot for signed PCR policies. Anyway, these are future topics and it's already good that we can make some encryption setups work.
As documented in flatcar/flatcar-website#317 we can use PCR binding in Flatcar with some limitations and workarounds. I think we should be able to get rid of the first boot PCR difference by handling the first-boot flag detection in userspace and if we can guarantee that the outcome of setting the first boot or not is the same, i.e., we would have to always measure the effective Ignition config. For the rebinding on update the best bet we have is to create a Flatcar variant with sd-boot for signed PCR policies. Anyway, these are future topics and it's already good that we can make some encryption setups work.
As documented in flatcar/flatcar-website#317 we can use PCR binding in Flatcar with some limitations and workarounds. I think we should be able to get rid of the first boot PCR difference by handling the first-boot flag detection in userspace and if we can guarantee that the outcome of setting the first boot or not is the same, i.e., we would have to always measure the effective Ignition config. For the rebinding on update the best bet we have is to create a Flatcar variant with sd-boot for signed PCR policies. Anyway, these are future topics and it's already good that we can make some encryption setups work.
As documented in flatcar/flatcar-website#317 we can use PCR binding in Flatcar with some limitations and workarounds. I think we should be able to get rid of the first boot PCR difference by handling the first-boot flag detection in userspace and if we can guarantee that the outcome of setting the first boot or not is the same, i.e., we would have to always measure the effective Ignition config. For the rebinding on update the best bet we have is to create a Flatcar variant with sd-boot for signed PCR policies. Anyway, these are future topics and it's already good that we can make some encryption setups work.
Tests added in flatcar/mantle#521 I also think we could try to unify the PCR values for the first boot and the other boots by not using a kernel parameter for first-boot or not but measure the effective Ignition config on every boot. |
For binding a secret to the OS we need TPM PCRs that measure the kernel and boot configuration (UEFI). Used for: flatcar/flatcar-website#317
A long-requested feature is disk encryption. In the next Alpha we have everything in place for TPM-backed disk encryption with systemd-cryptenroll and Clevis, and with a network-backed disk secret store with Tang. Document the limitations, implications and the Ignition configs.
That won't happen for this release, I'll merge it as is now and hope we can get rid of the first reboot soon. |
|
Azure Static Web Apps: Your stage site is ready! Visit it here: https://lemon-wave-085522403-317.westeurope.1.azurestaticapps.net |
A long-requested feature is disk encryption. In the next Alpha we have everything in place for TPM-backed disk encryption with systemd-cryptenroll and Clevis, and with a network-backed disk secret store with Tang.
Document the limitations, implications and the Ignition configs.
Preview URL suffix:
/docs/latest/setup/security/luks/