3143d86b69
Updates for patchset 2 review comments Changed link depth of main Planning index and added some narrative guidance Added planning/openstack as sibling of planning/kubernetes Related additions to abbrevs.txt Added max-workers substitution to accomodate StarlingX/vendor variants Signed-off-by: Ron Stone <ronald.stone@windriver.com> Change-Id: Ibff9af74ab3f2c00958eff0e33c91465f1dab6b4 Signed-off-by: Stone <ronald.stone@windriver.com>
2.7 KiB
Executable File
Kubernetes UEFI Secure Boot Planning
Secure Boot Planning allows you to authenticate modules before they are allowed to execute.
The initial installation of should be done in mode if you plan on using the secure boot feature in the future.
The secure boot certificate can be found in the ISO, on the EFI bootable FAT filesystem. The file is in the directory /CERTS. You must add this certificate database to the motherboard's certificate database. How to add this certificate to the database is determined by the implementation provided by the motherboard manufacturer.
You may need to work with your hardware vendor to have the certificate installed.
There is an option in the setup utility that allows a user to browse to a file containing a certificate to be loaded in the authorized database. This option may be hidden in the setup utility unless mode is enabled, and secure boot is enabled.
The implementation may or may not require a device to be present and enabled before providing for secure boot functionality. Refer to your server board's documentation.
Many motherboards ship with Microsoft secure boot certificates pre-programmed in the certificate database. These certificates may be required to boot drivers for video cards, controllers, or (for example, the boot software for a may have been signed by a Microsoft certificate). While certificates can be removed from the certificate database (this is implementation specific) it may be required that you keep the Microsoft certificates to allow for complete system operation.
Mixed combinations of secure boot and non-secure boot nodes are supported. For example, a controller node may secure boot, while a worker node may not. Secure boot must be enabled in the firmware of each node for that node to be protected by secure boot.
- Secure Boot is supported in installations only. It is not used when booting as a legacy boot target.
- does not currently support switching from legacy to mode after a system has been installed. Doing so requires a reinstall of the system. This means that upgrading from a legacy install to a secure boot install () is not supported.
- When upgrading a system from a version that did not support secure boot to a version that does, do not enable secure boot in firmware until the upgrade is complete.