Este conteúdo não está disponível no idioma selecionado.

Chapter 5. Configuring RHEL on Google Cloud with Secure Boot


To enhance boot security for a Red Hat Enterprise Linux (RHEL) instance on Google Cloud, configure Secure Boot. Secure Boot verifies the digital signatures of the boot loader and other components at startup, allowing only trusted programs to load while blocking unauthorized ones.

5.1. Understanding secure boot for RHEL on cloud

When Secure Boot detects any tampered components or components signed by untrusted entities, it aborts the boot process. Secure Boot plays a critical role in configuring a Confidential Virtual Machine (CVM) by ensuring that only trusted entities participate in the boot chain.

Secure Boot is a Unified Extensible Firmware Interface (UEFI) feature that verifies digital signatures of boot components, such as boot loader and kernel, against trusted keys stored in hardware. Secure Boot prevents unauthorized or tampered software from running during boot, protecting your system from malicious code. It authenticates access to specific device paths through defined interfaces, enforces the use of the latest configuration, and permanently overwrites earlier configurations. When the Red Hat Enterprise Linux (RHEL) kernel boots with Secure Boot enabled, it enters the lockdown mode, allowing only kernel modules signed by a trusted vendor to load. Therefore, Secure Boot strengthens the security of the operating system boot sequence.

Components of Secure Boot

The Secure Boot mechanism consists of firmware, signature databases, cryptographic keys, boot loader, hardware modules, and the operating system. The following are the components of the UEFI trusted variables:

  • Key Exchange Key database (KEK): An exchange of public keys to establish trust between the RHEL operating system and the VM firmware. You can also update Allowed Signature database (db) and Forbidden Signature database (dbx) by using these keys.
  • Platform Key database (PK): A self-signed single-key database to establish trust between the VM firmware and the cloud platform. The PK also updates the KEK database.
  • Allowed Signature database (db): A database that maintains a list of certificates or binary hashes to check whether the binary file can boot on the system. Additionally, all certificates from db are imported to the .platform keyring of the RHEL kernel. With this feature, you can add and load signed third party kernel modules in the lockdown mode.
  • Forbidden Signature database (dbx): A database that maintains a list of certificates or binary hashes that are not allowed to boot on the system.
Note

Binary files check against the dbx database and the Secure Boot Advanced Targeting (SBAT) mechanism. With SBAT, you can revoke older versions of specific binaries by keeping the certificate that has signed binaries as valid.

Stages of Secure Boot for RHEL on Cloud

When a RHEL instance boots in the Unified Kernel Image (UKI) mode and with Secure Boot enabled, the RHEL instance interacts with the cloud service infrastructure in the following sequence:

  1. Initialization: When a RHEL instance boots, the cloud-hosted firmware initially boots and implements the Secure Boot mechanism.
  2. Variable store initialization: The firmware initializes UEFI variables from a variable store, a dedicated storage area for information that firmware needs to manage for the boot process and runtime operations. When the RHEL instance boots for the first time, the store initializes from default values associated with the VM image.
  3. Boot loader: When booted, the firmware loads the first stage boot loader. For the RHEL instance in a x86 UEFI environment, the first stage boot loader is shim. The shim boot loader authenticates and loads the next stage of the boot process and acts as a bridge between UEFI and GRUB.

    1. The shim x86 binary in RHEL is currently signed by the Microsoft Corporation UEFI CA 2011 Microsoft certificate so that the RHEL instance can boot in the Secure Boot enabled mode on various hardware and virtualized platforms where the Allowed Signature database (db) has the default Microsoft certificates.
    2. The shim binary extends the list of trusted certificates with Red Hat Secure Boot CA and optionally, with Machine Owner Key (MOK).
  4. UKI: The shim binary loads the RHEL UKI (the kernel-uki-virt package). The corresponding certificate, Red Hat Secure Boot Signing 504 on the x86_64 architecture, signs the UKI. You can find this certificate in the redhat-sb-certs package. Red Hat Secure Boot CA signs this certificate, so the check succeeds.
  5. UKI add-ons: When you use the UKI cmdline extensions, the RHEL kernel actively checks their signatures against db, MOK, and certificates shipped with shim. This process ensures that either the operating system vendor RHEL or a user has signed the extensions.

When the RHEL kernel boots in the Secure Boot mode, it enters the lockdown mode. After entering lockdown, the RHEL kernel adds the db keys to the .platform keyring and the MOK keys to the .machine keyring. During the kernel build process, the build system works with an ephemeral key, which consists of private and public keys. The build system signs standard RHEL kernel modules, such as kernel-modules-core, kernel-modules, and kernel-modules-extra. After the completion of each kernel build, the private key becomes obsolete to sign third-party modules. You can use certificates from db and MOK for this purpose.

5.2. Configuring a RHEL instance from a custom RHEL image with Secure Boot

To ensure that your Red Hat Enterprise Linux (RHEL) instance on Google Cloud has a secured operating system booting process, use the Secure Boot mechanism. You can configure the Secure Boot during registration of a custom RHEL Google Cloud image.

Prerequisites

  • You have created and uploaded a RHEL Google Cloud image.
  • You have installed the following packages:

    • python3
    • keyutils
    • openssl
    • python3-virt-firmware
  • You have installed the google-cloud-cli utility.
  • You have included a custom certificate in the SecureBoot DB to sign custom artifacts, such as third party kernel modules and Unified Kernel Image (UKI) add-ons.

Procedure

  1. Generate a custom certificate custom_db.cer:

    $ openssl req -quiet \
    -newkey rsa:4096 \
    -nodes -keyout custom_db.key \
    -new -x509 -sha256 \
    -days 3650 \
    -subj "/CN=Signature Database key/" \
    -outform DER \
    -out custom_db.cer
  2. Convert the certificates to the Distinguished Encoding Rules (DER) format.

    1. To convert a Platform Key database (PK) certificate, enter:

      $ openssl x509 -in /usr/lib/python3.9/site-packages/virt/firmware/certs/redhat.com/rh-pk-kek-2014.pem -inform PEM -out rh-pk-kek-2014.cer -outform DER
    2. To convert a Key Exchange Key database (KEK) certificate, enter:

      $ openssl x509 -in /usr/lib/python3.9/site-packages/virt/firmware/certs/microsoft.com/ms-uefi-2023.pem -inform PEM -out ms-uefi-2023.cer -outform DER
    3. To convert a allowed signature database (db) certificate, enter:

      $ openssl x509 -in /usr/lib/python3.9/site-packages/virt/firmware/certs/microsoft.com/ms-kek-2023.pem -inform PEM -out ms-kek-2023.cer -outform DER
  3. Use the google-cloud-cli utility to create and register the image from a disk snapshot with the required Secure Boot variables:

    $ gcloud compute images create <example-rhel-9-efi-image> \
    --source-image projects/<example_project_id>/global/images/<example_image_name> \
    --platform-key-file=rh-pk-kek-2014.cer \
    --key-exchange-key-file=rh-pk-kek-2014.cer,ms-kek-2023.cer \
    --signature-database-file=custom_db.cer,ms-uefi-2023.cer \
    --forbidden-database-file /usr/share/edk2/ovmf/DBXUpdate*.bin \
    --guest-os-features="UEFI_COMPATIBLE"
  4. Launch the instance of an example-rhel-9-efi-image image with the Turn on Security Boot feature from the Google Cloud console.

    Secure Boot for RHEL Google Cloud instance

Verification

  1. Verify if Secure Boot is enabled:

    $ mokutil --sb-state
    SecureBoot enabled
  2. Verify the kernel keyring for the custom certificate:

    $ sudo keyctl list %:.platform
    ...
    757453569: ---lswrv     0     0 asymmetric: Signature Database key: f064979641c24e1b935e402bdbc3d5c4672a1acc
    ...

5.3. Configuring a RHEL instance on the Google Cloud Marketplace with Secure Boot

Enable Secure Boot for a Red Hat Enterprise Linux (RHEL) instance on Google Cloud to secure the operating system (OS) boot process. By default, Secure Boot uses the Allowed Signature database (db) containing Microsoft certificates.

Prerequisites

  • You have an account on Google Cloud. For details, see Google Cloud.

Procedure

  1. Launch a publicly available Red Hat Enterprise Linux instance from Google Cloud console.
  2. Install the keyutils package:

    $ dnf install keyutils
  3. Enable the Turn on Secure Boot option on the RHEL Google Cloud instance:

    Secure Boot for RHEL Google Cloud instance

Verification

  1. Verify if Secure Boot is enabled:

    $ mokutil --sb-state
    
    SecureBoot enabled
  2. Verify the kernel keyring for the custom certificate:

    $ sudo keyctl list %:.platform
    
    4 keys in keyring:
    12702216: ---lswrv     0     0 asymmetric: Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed522988a1bd4
    449796228: ---lswrv     0     0 asymmetric: Red Hat Secure Boot CA 8: e1c6c580aa1e21d585aad9bf20f3929e5ec1f08b
    50338534: ---lswrv     0     0 asymmetric: Red Hat Secure Boot CA 5: cc6fa5e72868ba494e939bbd680b9144769a9f8f
    681047026: ---lswrv     0     0 asymmetric: Microsoft Windows Production PCA 2011: a92902398e16c49778cd90f99e4f9ae17c55af53
Red Hat logoGithubredditYoutubeTwitter

Aprender

Experimente, compre e venda

Comunidades

Sobre a documentação da Red Hat

Ajudamos os usuários da Red Hat a inovar e atingir seus objetivos com nossos produtos e serviços com conteúdo em que podem confiar. Explore nossas atualizações recentes.

Tornando o open source mais inclusivo

A Red Hat está comprometida em substituir a linguagem problemática em nosso código, documentação e propriedades da web. Para mais detalhes veja o Blog da Red Hat.

Sobre a Red Hat

Fornecemos soluções robustas que facilitam o trabalho das empresas em plataformas e ambientes, desde o data center principal até a borda da rede.

Theme

© 2026 Red Hat
Voltar ao topo