Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Deploying RHEL 9 on Google Cloud Platform

Red Hat Enterprise Linux 9

Obtaining RHEL system images and creating RHEL instances on GCP

Red Hat Customer Content Services

Abstract

To use Red Hat Enterprise Linux (RHEL) in a public cloud environment, you can create and deploy RHEL system images on various cloud platforms, including Google Cloud Platform (GCP). You can also create and configure a Red Hat High Availability (HA) cluster on GCP.
The following chapters provide instructions for creating cloud RHEL instances and HA clusters on GCP. These processes include installing the required packages and agents, configuring fencing, and installing network resource agents.

Providing feedback on Red Hat documentation
Copy link

We appreciate your feedback on our documentation. Let us know how we can improve it.

Submitting feedback through Jira (account required)

  1. Log in to the Jira website.
  2. Click Create in the top navigation bar
  3. Enter a descriptive title in the Summary field.
  4. Enter your suggestion for improvement in the Description field. Include links to the relevant parts of the documentation.
  5. Click Create at the bottom of the dialogue.

Public cloud platforms offer computing resources as a service. Instead of using on-premise hardware, you can run your IT workloads, including Red Hat Enterprise Linux (RHEL) systems, as public cloud instances.

1.1. Benefits of using RHEL in a public cloud
Copy link

RHEL as a cloud instance located on a public cloud platform has the following benefits over RHEL on-premises physical systems or virtual machines (VMs):

  • Flexible and fine-grained allocation of resources

    A cloud instance of RHEL runs as a VM on a cloud platform, which typically means a cluster of remote servers maintained by the provider of the cloud service. Therefore, allocating hardware resources to the instance, such as a specific type of CPU or storage, happens on the software level and is easily customizable.

    In comparison to a local RHEL system, you are also not limited by the capabilities of your physical host. Instead, you can choose from a variety of features, based on selection offered by the cloud provider.

  • Space and cost efficiency

    You do not need to own any on-premises servers to host your cloud workloads. This avoids the space, power, and maintenance requirements associated with physical hardware.

    Instead, on public cloud platforms, you pay the cloud provider directly for using a cloud instance. The cost is typically based on the hardware allocated to the instance and the time you spend using it. Therefore, you can optimize your costs based on your requirements.

  • Software-controlled configurations

    The entire configuration of a cloud instance is saved as data on the cloud platform, and is controlled by software. Therefore, you can easily create, remove, clone, or migrate the instance. A cloud instance is also operated remotely in a cloud provider console and is connected to remote storage by default.

    In addition, you can back up the current state of a cloud instance as a snapshot at any time. Afterwards, you can load the snapshot to restore the instance to the saved state.

  • Separation from the host and software compatibility

    Similarly to a local VM, the RHEL guest operating system on a cloud instance runs on a virtualized kernel. This kernel is separate from the host operating system and from the client system that you use to connect to the instance.

    Therefore, any operating system can be installed on the cloud instance. This means that on a RHEL public cloud instance, you can run RHEL-specific applications that cannot be used on your local operating system.

    In addition, even if the operating system of the instance becomes unstable or is compromised, your client system is not affected in any way.

1.2. Public cloud use cases for RHEL
Copy link

Deploying on a public cloud provides many benefits, but might not be the most efficient solution in every scenario. If you are evaluating whether to migrate your RHEL deployments to the public cloud, consider whether your use case will benefit from the advantages of the public cloud.

Beneficial use cases

  • Deploying public cloud instances is very effective for flexibly increasing and decreasing the active computing power of your deployments, also known as scaling up and scaling down. Therefore, using RHEL on public cloud is recommended in the following scenarios:

    • Clusters with high peak workloads and low general performance requirements. Scaling up and down based on your demands can be highly efficient in terms of resource costs.
    • Quickly setting up or expanding your clusters. This avoids high upfront costs of setting up local servers.
  • Cloud instances are not affected by what happens in your local environment. Therefore, you can use them for backup and disaster recovery.

Potentially problematic use cases

  • You are running an existing environment that cannot be adjusted. Customizing a cloud instance to fit the specific needs of an existing deployment may not be cost-effective in comparison with your current host platform.
  • You are operating with a hard limit on your budget. Maintaining your deployment in a local data center typically provides less flexibility but more control over the maximum resource costs than the public cloud does.

Next steps

Moving your RHEL workloads from a local environment to a public cloud platform might raise concerns about the changes involved. The following are the most commonly asked questions.

Will my RHEL work differently as a cloud instance than as a local virtual machine?

In most respects, RHEL instances on a public cloud platform work the same as RHEL virtual machines on a local host, such as an on-premises server. Notable exceptions include:

  • Instead of private orchestration interfaces, public cloud instances use provider-specific console interfaces for managing your cloud resources.
  • Certain features, such as nested virtualization, may not work correctly. If a specific feature is critical for your deployment, check the feature’s compatibility in advance with your chosen public cloud provider.

Will my data stay safe in a public cloud as opposed to a local server?

The data in your RHEL cloud instances is in your ownership, and your public cloud provider does not have any access to it. In addition, major cloud providers support data encryption in transit, which improves the security of data when migrating your virtual machines to the public cloud.

The general security of your RHEL public cloud instances is managed as follows:

  • Your public cloud provider is responsible for the security of the cloud hypervisor
  • Red Hat provides the security features of the RHEL guest operating systems in your instances
  • You manage the specific security settings and practices in your cloud infrastructure

What effect does my geographic region have on the functionality of RHEL public cloud instances?

You can use RHEL instances on a public cloud platform regardless of your geographical location. Therefore, you can run your instances in the same region as your on-premises server.

However, hosting your instances in a physically distant region might cause high latency when operating them. In addition, depending on the public cloud provider, certain regions may provide additional features or be more cost-efficient. Before creating your RHEL instances, review the properties of the hosting regions available for your chosen cloud provider.

1.4. Obtaining RHEL for public cloud deployments
Copy link

To deploy a RHEL system in a public cloud environment, you need to:

  1. Select the optimal cloud provider for your use case, based on your requirements and the current offer on the market.

    The cloud providers currently certified for running RHEL instances are:

  2. Create a RHEL cloud instance on your chosen cloud platform. For more information, see Methods for creating RHEL cloud instances.
  3. To keep your RHEL deployment up-to-date, use Red Hat Update Infrastructure (RHUI).

1.5. Methods for creating RHEL cloud instances
Copy link

To deploy a RHEL instance on a public cloud platform, you can use one of the following methods:

Expand

Create a system image of RHEL and import it to the cloud platform.

  • To create the system image, you can use the RHEL image builder or you can build the image manually.
  • This method uses your existing RHEL subscription, and is also referred to as bring your own subscription (BYOS).
  • You pre-pay a yearly subscription, and you can use your Red Hat customer discount.
  • Your customer service is provided by Red Hat.
  • For creating multiple images effectively, you can use the cloud-init tool.

Purchase a RHEL instance directly from the cloud provider marketplace.

  • You post-pay an hourly rate for using the service. Therefore, this method is also referred to as pay as you go (PAYG).
  • Your customer service is provided by the cloud platform provider.
Note

For detailed instructions on using various methods to deploy RHEL instances on Google Cloud Platform, see the following chapters in this document.

With RHEL image builder, you can build a gce image, provide credentials for your user or GCP service account, and then upload the gce image directly to the GCP environment.

Set up a configuration file with credentials to upload your gce image to GCP by using the RHEL image builder CLI.

Warning

You cannot manually import gce image to GCP, because the image will not boot. You must use either gcloud or RHEL image builder to upload it.

Prerequisites

  • You have a valid Google account and credentials to upload your image to GCP. The credentials can be from a user account or a service account. The account associated with the credentials must have at least the following IAM roles assigned:

    • roles/storage.admin - to create and delete storage objects
    • roles/compute.storageAdmin - to import a VM image to Compute Engine.
  • You have an existing GCP bucket.

Procedure

  1. Use a text editor to create a gcp-config.toml configuration file with the following content: 

    provider = "gcp"
[settings]
bucket = "GCP_BUCKET"
region = "GCP_STORAGE_REGION"
object = "OBJECT_KEY"
credentials = "GCP_CREDENTIALS"
    Copy to Clipboard Toggle word wrap
    • GCP_BUCKET points to an existing bucket. It is used to store the intermediate storage object of the image which is being uploaded.
    • GCP_STORAGE_REGION is both a regular Google storage region and a dual or multi region.
    • OBJECT_KEY is the name of an intermediate storage object. It must not exist before the upload, and it is deleted when the upload process is done. If the object name does not end with .tar.gz, the extension is automatically added to the object name.

    • GCP_CREDENTIALS is a Base64-encoded scheme of the credentials JSON file downloaded from GCP. The credentials determine which project the GCP uploads the image to.

      Note

      Specifying GCP_CREDENTIALS in the gcp-config.toml file is optional if you use a different mechanism to authenticate with GCP. For other authentication methods, see Authenticating with GCP.

  2. Retrieve the GCP_CREDENTIALS from the JSON file downloaded from GCP. 

    $ sudo base64 -w 0 cee-gcp-nasa-476a1fa485b7.json
    Copy to Clipboard Toggle word wrap

  3. Create a compose with an additional image name and cloud provider profile: 

    $ sudo composer-cli compose start BLUEPRINT-NAME gce IMAGE_KEY gcp-config.toml
    Copy to Clipboard Toggle word wrap

    The image build, upload, and cloud registration processes can take up to ten minutes to complete.

Verification

  • Verify that the image status is FINISHED: 

    $ sudo composer-cli compose status
    Copy to Clipboard Toggle word wrap

You can use several different types of credentials with RHEL image builder to authenticate with GCP. If RHEL image builder configuration is set to authenticate with GCP using multiple sets of credentials, it uses the credentials in the following order of preference:

  1. Credentials specified with the composer-cli command in the configuration file.
  2. Credentials configured in the osbuild-composer worker configuration.

  3. Application Default Credentials from the Google GCP SDK library, which tries to automatically find a way to authenticate by using the following options:

    1. If the GOOGLE_APPLICATION_CREDENTIALS environment variable is set, Application Default Credentials tries to load and use credentials from the file pointed to by the variable.

    2. Application Default Credentials tries to authenticate by using the service account attached to the resource that is running the code. For example, Google Compute Engine VM.

      Note

      You must use the GCP credentials to determine which GCP project to upload the image to. Therefore, unless you want to upload all of your images to the same GCP project, you always must specify the credentials in the gcp-config.toml configuration file with the composer-cli command.

You can specify GCP authentication credentials in the upload target configuration gcp-config.toml file. Use a Base64-encoded scheme of the Google account credentials JSON file to save time.

Procedure

  1. Get the encoded content of the Google account credentials file with the path stored in GOOGLE_APPLICATION_CREDENTIALS environment variable, by running the following command: 

    $ base64 -w 0 "${GOOGLE_APPLICATION_CREDENTIALS}"
    Copy to Clipboard Toggle word wrap

  2. In the upload target configuration gcp-config.toml file, set the credentials: 

    provider = "gcp"

[settings]
provider = "gcp"

[settings]
credentials = "GCP_CREDENTIALS"
    Copy to Clipboard Toggle word wrap

You can configure GCP authentication credentials to be used for GCP globally for all image builds. This way, if you want to import images to the same GCP project, you can use the same credentials for all image uploads to GCP.

Procedure

  • In the /etc/osbuild-worker/osbuild-worker.toml worker configuration, set the following credential value: 

    [gcp]
credentials = "PATH_TO_GCP_ACCOUNT_CREDENTIALS"
    Copy to Clipboard Toggle word wrap

To set up a deployment of Red Hat Enterprise Linux 9 (RHEL 9) on Google Cloud Platform (GCP), you can deploy RHEL 9 as a Google Compute Engine (GCE) instance on GCP.

Note

For a list of Red Hat product certifications for GCP, see Red Hat on Google Cloud Platform.

Important

You can create a custom VM from an ISO image, but Red Hat recommends that you use the Red Hat Image Builder product to create customized images for use on specific cloud providers. See Composing a Customized RHEL System Image for more information.

Prerequisites

  • You need a Red Hat Customer Portal account to complete the procedures in this chapter.
  • Create an account with GCP to access the Google Cloud Platform Console. See Google Cloud for more information.

3.1. Red Hat Enterprise Linux image options on GCP
Copy link

You can use multiple types of images for deploying RHEL 9 on Google Cloud Platform. Based on your requirements, consider which option is optimal for your use case.

Expand
Table 3.1. Image options
Image optionSubscriptionsSample scenarioConsiderations

Deploy a Red Hat Gold Image.

Use your existing Red Hat subscriptions.

Select a Red Hat Gold Image on Google Cloud Platform. For details on Gold Images and how to access them on Google Cloud Platform, see the Red Hat Cloud Access Reference Guide.

The subscription includes the Red Hat product cost; you pay Google for all other instance costs. Red Hat provides support directly for custom RHEL images.

Deploy a custom image that you move to GCP.

Use your existing Red Hat subscriptions.

Upload your custom image and attach your subscriptions.

The subscription includes the Red Hat product cost; you pay all other instance costs. Red Hat provides support directly for custom RHEL images.

Deploy an existing GCP image that includes RHEL.

The GCP images include a Red Hat product.

Choose a RHEL image when you launch an instance on the GCP Compute Engine, or choose an image from the Google Cloud Platform Marketplace.

You pay GCP hourly on a pay-as-you-go model. Such images are called "on-demand" images. GCP offers support for on-demand images through a support agreement.

Note

You can create a custom image for GCP by using Red Hat Image Builder. See Composing a Customized RHEL System Image for more information.

Important

You cannot convert an on-demand instance to a custom RHEL instance. To change from an on-demand image to a custom RHEL bring-your-own-subscription (BYOS) image:

  1. Create a new custom RHEL instance and migrate data from your on-demand instance.
  2. Cancel your on-demand instance after you migrate your data to avoid double billing.

3.2. Understanding base images
Copy link

To create a base VM from an ISO image, you can use preconfigured base images and their configuration settings.

3.2.1. Using a custom base image
Copy link

To manually configure a virtual machine (VM), first create a base (starter) VM image. Then, you can modify configuration settings and add the packages the VM requires to operate on the cloud. You can make additional configuration changes for your specific application after you upload the image.

3.2.2. Virtual machine configuration settings
Copy link

Cloud VMs must have the following configuration settings.

Expand
Table 3.2. VM configuration settings
SettingRecommendation

ssh

ssh must be enabled to provide remote access to your VMs.

dhcp

The primary virtual adapter should be configured for dhcp.

3.3. Creating a base VM from an ISO image
Copy link

To create a RHEL 9 base image from an ISO image, enable your host machine for virtualization and create a RHEL virtual machine (VM).

Prerequisites

3.3.1. Creating a VM from the RHEL ISO image
Copy link

Procedure

  1. Ensure that you have enabled your host machine for virtualization. See Enabling virtualization in RHEL 9 for information and procedures.

  2. Create and start a basic Red Hat Enterprise Linux VM. For instructions, see Creating virtual machines.

    1. If you use the command line to create your VM, ensure that you set the default memory and CPUs to the capacity you want for the VM. Set your virtual network interface to virtio.

      For example, the following command creates a kvmtest VM by using the /home/username/Downloads/rhel9.iso image: 

      # virt-install \
    --name kvmtest --memory 2048 --vcpus 2 \
    --cdrom /home/username/Downloads/rhel9.iso,bus=virtio \
    --os-variant=rhel9.0
      Copy to Clipboard Toggle word wrap

    2. If you use the web console to create your VM, follow the procedure in Creating virtual machines by using the web console, with these caveats:

      • Do not check Immediately Start VM.
      • Change your Memory size to your preferred settings.
      • Before you start the installation, ensure that you have changed Model under Virtual Network Interface Settings to virtio and change your vCPUs to the capacity settings you want for the VM.

3.3.2. Completing the RHEL installation
Copy link

To finish the installation of a RHEL system that you want to deploy on Amazon Web Services (AWS), customize the Installation Summary view, begin the installation, and enable root access once the VM launches.

Procedure

  1. Choose the language you want to use during the installation process.

  2. On the Installation Summary view:

    1. Click Software Selection and check Minimal Install.
    2. Click Done.

    3. Click Installation Destination and check Custom under Storage Configuration.

      • Verify at least 500 MB for /boot. You can use the remaining space for root /.
      • Standard partitions are recommended, but you can use Logical Volume Manager (LVM).
      • You can use xfs, ext4, or ext3 for the file system.
      • Click Done when you are finished with changes.
  3. Click Begin Installation.
  4. Set a Root Password. Create other users as applicable.
  5. Reboot the VM and log in as root once the installation completes.

  6. Configure the image.

    1. Register the VM and enable the Red Hat Enterprise Linux 9 repository. 

      # subscription-manager register
      Copy to Clipboard Toggle word wrap

    2. Ensure that the cloud-init package is installed and enabled. 

      # dnf install cloud-init
# systemctl enable --now cloud-init.service
      Copy to Clipboard Toggle word wrap
  7. Power off the VM.

3.4. Uploading the RHEL image to GCP
Copy link

To run your RHEL 9 instance on Google Cloud Platform (GCP), you must upload your RHEL 9 image to GCP.

3.4.1. Creating a new project on GCP
Copy link

To upload your Red Hat Enterprise Linux 9 image to Google Cloud Platform (GCP), you must first create a new project on GCP.

Prerequisites

  • You must have an account with GCP. If you do not, see Google Cloud for more information.

Procedure

  1. Launch the GCP Console.
  2. Click the drop-down menu to the right of Google Cloud Platform.
  3. From the pop-up menu, click NEW PROJECT.
  4. From the New Project window, enter a name for your new project.
  5. Check Organization. Click the drop-down menu to change the organization, if necessary.
  6. Confirm the Location of your parent organization or folder. Click Browse to search for and change this value, if necessary.

  7. Click CREATE to create your new GCP project.

    Note

    Once you have installed the Google Cloud SDK, you can use the gcloud projects create CLI command to create a project. For example: 

    # gcloud projects create my-gcp-project3 --name project3
    Copy to Clipboard Toggle word wrap

    The example creates a project with the project ID my-gcp-project3 and the project name project3. See gcloud project create for more information.

3.4.2. Installing the Google Cloud SDK
Copy link

Many of the procedures to manage HA clusters on Google Cloud Platform (GCP) require the tools in the Google Cloud SDK.

Procedure

  1. Follow the GCP instructions for downloading and extracting the Google Cloud SDK archive. See the GCP document Quickstart for Linux for details.

  2. Follow the same instructions for initializing the Google Cloud SDK.

    Note

    Once you have initialized the Google Cloud SDK, you can use the gcloud CLI commands to perform tasks and obtain information about your project and instances. For example, you can display project information with the gcloud compute project-info describe --project <project-name> command.

3.4.3. Creating SSH keys for Google Compute Engine
Copy link

Generate and register SSH keys with GCE so that you can SSH directly into an instance by using its public IP address.

Procedure

  1. Use the ssh-keygen command to generate an SSH key pair for use with GCE. 

    # ssh-keygen -t rsa -f ~/.ssh/google_compute_engine
    Copy to Clipboard Toggle word wrap
  2. From the GCP Console Dashboard page, click the Navigation menu to the left of the Google Cloud Console banner and select Compute Engine and then select Metadata.
  3. Click SSH Keys and then click Edit.

  4. Enter the output generated from the ~/.ssh/google_compute_engine.pub file and click Save.

    You can now connect to your instance by using standard SSH. 

    # ssh -i ~/.ssh/google_compute_engine <username>@<instance_external_ip>
    Copy to Clipboard Toggle word wrap
Note

You can run the gcloud compute config-ssh command to populate your config file with aliases for your instances. The aliases allow simple SSH connections by instance name. For information about the gcloud compute config-ssh command, see gcloud compute config-ssh.

3.4.4. Creating a storage bucket in GCP Storage
Copy link

To import your RHEL 9 image to GCP, you must first create a GCP Storage Bucket.

Procedure

  1. If you are not already logged in to GCP, log in with the following command. 

    # gcloud auth login
    Copy to Clipboard Toggle word wrap

  2. Create a storage bucket. 

    # gsutil mb gs://bucket_name
    Copy to Clipboard Toggle word wrap
    Note

    Alternatively, you can use the Google Cloud Console to create a bucket. See Create a bucket for information.

Before a local RHEL 9 image can be deployed in GCP, you must first convert and upload the image to your GCP Bucket. The following steps describe converting an qcow2 image to raw format and then uploading the image as a tar archive. However, using different formats is possible as well.

Procedure

  1. Run the qemu-img command to convert your image. The converted image must have the name disk.raw. 

    # qemu-img convert -f qcow2 -O raw rhel-9.0-sample.qcow2 disk.raw
    Copy to Clipboard Toggle word wrap

  2. Tar the image. 

    # tar --format=oldgnu -Sczf disk.raw.tar.gz disk.raw
    Copy to Clipboard Toggle word wrap

  3. Upload the image to the bucket you created previously. Upload could take a few minutes. 

    # gsutil cp disk.raw.tar.gz gs://bucket_name
    Copy to Clipboard Toggle word wrap
  4. From the Google Cloud Platform home screen, click the collapsed menu icon and select Storage and then select Browser.

  5. Click the name of your bucket.

    The tarred image is listed under your bucket name.

    Note

    You can also upload your image by using the GCP Console. To do so, click the name of your bucket and then click Upload files.

Before you can create a GCE image from an object that you uploaded to your GCP bucket, you must convert the object into a GCE image.

Procedure

  1. Run the following command to create an image for GCE. Specify the name of the image you are creating, the bucket name, and the name of the tarred image. 

    # gcloud compute images create my-image-name --source-uri gs://my-bucket-name/disk.raw.tar.gz
    Copy to Clipboard Toggle word wrap
    Note

    Alternatively, you can use the Google Cloud Console to create an image. See Creating, deleting, and deprecating custom images for more information.

  2. Optional: Find the image in the GCP Console.

    1. Click the Navigation menu to the left of the Google Cloud Console banner.
    2. Select Compute Engine and then Images.

To configure a GCE VM instance from an image, use the GCP Console.

Note

See Creating and starting a VM instance for more information about GCE VM instances and their configuration options.

Procedure

  1. From the GCP Console Dashboard page, click the Navigation menu to the left of the Google Cloud Console banner and select Compute Engine and then select Images.
  2. Select your image.
  3. Click Create Instance.
  4. On the Create an instance page, enter a Name for your instance.
  5. Choose a Region and Zone.
  6. Choose a Machine configuration that meets or exceeds the requirements of your workload.
  7. Ensure that Boot disk specifies the name of your image.
  8. Optional: Under Firewall, select Allow HTTP traffic or Allow HTTPS traffic.

  9. Click Create.

    Note

    These are the minimum configuration options necessary to create a basic instance. Review additional options based on your application requirements.

  10. Find your image under VM instances.

  11. From the GCP Console Dashboard, click the Navigation menu to the left of the Google Cloud Console banner and select Compute Engine and then select VM instances.

    Note

    Alternatively, you can use the gcloud compute instances create CLI command to create a GCE VM instance from an image. A simple example follows. 

    gcloud compute instances create myinstance3 --zone=us-central1-a --image test-iso2-image
    Copy to Clipboard Toggle word wrap

    The example creates a VM instance named myinstance3 in zone us-central1-a based upon the existing image test-iso2-image. See gcloud compute instances create for more information.

3.4.8. Connecting to your instance
Copy link

Connect to your GCE instance by using its public IP address.

Procedure

  1. Ensure that your instance is running. The following command lists information about your GCE instance, including whether the instance is running, and, if so, the public IP address of the running instance. 

    # gcloud compute instances list
    Copy to Clipboard Toggle word wrap

  2. Connect to your instance by using standard SSH. The example uses the google_compute_engine key created earlier. 

    # ssh -i ~/.ssh/google_compute_engine <user_name>@<instance_external_ip>
    Copy to Clipboard Toggle word wrap
    Note

    GCP offers a number of ways to SSH into your instance. See Connecting to instances for more information. You can also connect to your instance using the root account and password you set previously.

3.4.9. Attaching Red Hat subscriptions
Copy link

Using the subscription-manager command, you can register and attach your Red Hat subscription to a RHEL instance.

Prerequisites

  • You must have enabled your subscriptions.

Procedure

  1. Register your system. 

    # subscription-manager register
    Copy to Clipboard Toggle word wrap

  2. Attach your subscriptions.

  3. Optional: To collect various system metrics about the instance in the Red Hat Hybrid Cloud Console, you can register the instance with Red Hat Insights. 

    # insights-client register --display-name <display_name_value>
    Copy to Clipboard Toggle word wrap

    For information about further configuration of Red Hat Insights, see Client Configuration Guide for Red Hat Insights.

To create a cluster where RHEL nodes automatically redistribute their workloads if a node failure occurs, use the Red Hat High Availability Add-On. Such high availability (HA) clusters can also be hosted on public cloud platforms, including Google Cloud Platform (GCP). Creating RHEL HA clusters on GCP is similar to creating HA clusters in non-cloud environments, with certain specifics.

To configure a Red Hat HA cluster on Google Cloud Platform (GCP) using Google Compute Engine (GCE) virtual machine (VM) instances as cluster nodes, see the following sections.

These provide information on:

  • Prerequisite procedures for setting up your environment for GCP. Once you have set up your environment, you can create and configure VM instances.
  • Procedures specific to the creation of HA clusters, which transform individual nodes into a cluster of HA nodes on GCP. These include procedures for installing the High Availability packages and agents on each cluster node, configuring fencing, and installing network resource agents.

Prerequisites

  • Red Hat Enterprise Linux 9 Server: rhel-9-server-rpms/8Server/x86_64

  • Red Hat Enterprise Linux 9 Server (High Availability): rhel-9-server-ha-rpms/8Server/x86_64

    • You must belong to an active GCP project and have sufficient permissions to create resources in the project.
    • Your project should have a service account that belongs to a VM instance and not an individual user. See Using the Compute Engine Default Service Account for information about using the default service account instead of creating a separate service account.

If you or your project administrator create a custom service account, the service account should be configured for the following roles.

  • Cloud Trace Agent
  • Compute Admin
  • Compute Network Admin
  • Cloud Datastore User
  • Logging Admin
  • Monitoring Editor
  • Monitoring Metric Writer
  • Service Account Administrator
  • Storage Admin

A high-availability (HA) cluster is a set of computers (called nodes) that are linked together to run a specific workload. The purpose of HA clusters is to provide redundancy in case of a hardware or software failure. If a node in the HA cluster fails, the Pacemaker cluster resource manager distributes the workload to other nodes and no noticeable downtime occurs in the services that are running on the cluster.

You can also run HA clusters on public cloud platforms. In this case, you would use virtual machine (VM) instances in the cloud as the individual cluster nodes. Using HA clusters on a public cloud platform has the following benefits:

  • Improved availability: In case of a VM failure, the workload is quickly redistributed to other nodes, so running services are not disrupted.
  • Scalability: Additional nodes can be started when demand is high and stopped when demand is low.
  • Cost-effectiveness: With the pay-as-you-go pricing, you pay only for nodes that are running.
  • Simplified management: Some public cloud platforms offer management interfaces to make configuring HA clusters easier.

To enable HA on your Red Hat Enterprise Linux (RHEL) systems, Red Hat offers a High Availability Add-On. The High Availability Add-On provides all necessary components for creating HA clusters on RHEL systems. The components include high availability service management and cluster administration tools.

4.2. Required system packages
Copy link

To create and configure a base image of RHEL, your host system must have the following packages installed.

Expand
Table 4.1. System packages
PackageRepositoryDescription

libvirt

rhel-9-for-x86_64-appstream-rpms

Open source API, daemon, and management tool for managing platform virtualization

virt-install

rhel-9-for-x86_64-appstream-rpms

A command-line utility for building VMs

libguestfs

rhel-9-for-x86_64-appstream-rpms

A library for accessing and modifying VM file systems

guestfs-tools

rhel-9-for-x86_64-appstream-rpms

System administration tools for VMs; includes the virt-customize utility

4.3. Red Hat Enterprise Linux image options on GCP
Copy link

You can use multiple types of images for deploying RHEL 9 on Google Cloud Platform. Based on your requirements, consider which option is optimal for your use case.

Expand
Table 4.2. Image options
Image optionSubscriptionsSample scenarioConsiderations

Deploy a Red Hat Gold Image.

Use your existing Red Hat subscriptions.

Select a Red Hat Gold Image on Google Cloud Platform. For details on Gold Images and how to access them on Google Cloud Platform, see the Red Hat Cloud Access Reference Guide.

The subscription includes the Red Hat product cost; you pay Google for all other instance costs. Red Hat provides support directly for custom RHEL images.

Deploy a custom image that you move to GCP.

Use your existing Red Hat subscriptions.

Upload your custom image and attach your subscriptions.

The subscription includes the Red Hat product cost; you pay all other instance costs. Red Hat provides support directly for custom RHEL images.

Deploy an existing GCP image that includes RHEL.

The GCP images include a Red Hat product.

Choose a RHEL image when you launch an instance on the GCP Compute Engine, or choose an image from the Google Cloud Platform Marketplace.

You pay GCP hourly on a pay-as-you-go model. Such images are called "on-demand" images. GCP offers support for on-demand images through a support agreement.

Note

You can create a custom image for GCP by using Red Hat Image Builder. See Composing a Customized RHEL System Image for more information.

Important

You cannot convert an on-demand instance to a custom RHEL instance. To change from an on-demand image to a custom RHEL bring-your-own-subscription (BYOS) image:

  1. Create a new custom RHEL instance and migrate data from your on-demand instance.
  2. Cancel your on-demand instance after you migrate your data to avoid double billing.

4.4. Installing the Google Cloud SDK
Copy link

Many of the procedures to manage HA clusters on Google Cloud Platform (GCP) require the tools in the Google Cloud SDK.

Procedure

  1. Follow the GCP instructions for downloading and extracting the Google Cloud SDK archive. See the GCP document Quickstart for Linux for details.

  2. Follow the same instructions for initializing the Google Cloud SDK.

    Note

    Once you have initialized the Google Cloud SDK, you can use the gcloud CLI commands to perform tasks and obtain information about your project and instances. For example, you can display project information with the gcloud compute project-info describe --project <project-name> command.

4.5. Creating a GCP image bucket
Copy link

The following document includes the minimum requirements for creating a multi-regional bucket in your default location.

Prerequisites

  • GCP storage utility (gsutil)

Procedure

  1. If you are not already logged in to Google Cloud Platform, log in with the following command. 

    # gcloud auth login
    Copy to Clipboard Toggle word wrap

  2. Create a storage bucket. 

    $ gsutil mb gs://BucketName
    Copy to Clipboard Toggle word wrap

    Example: 

    $ gsutil mb gs://rhel-ha-bucket
    Copy to Clipboard Toggle word wrap

A custom virtual private cloud (VPC) network and subnet are required for a cluster to be configured with a High Availability (HA) function.

Procedure

  1. Launch the GCP Console.
  2. Select VPC networks under Networking in the left navigation pane.
  3. Click Create VPC Network.
  4. Enter a name for the VPC network.
  5. Under the New subnet, create a Custom subnet in the region where you want to create the cluster.
  6. Click Create.

4.7. Preparing and importing a base GCP image
Copy link

Before a local RHEL 9 image can be deployed in GCP, you must first convert and upload the image to your GCP Bucket.

Procedure

  1. Convert the file. Images uploaded to GCP must be in raw format and named disk.raw. 

    $ qemu-img convert -f qcow2 ImageName.qcow2 -O raw disk.raw
    Copy to Clipboard Toggle word wrap

  2. Compress the raw file. Images uploaded to GCP must be compressed. 

    $ tar -Sczf ImageName.tar.gz disk.raw
    Copy to Clipboard Toggle word wrap

  3. Import the compressed image to the bucket created earlier. 

    $ gsutil cp ImageName.tar.gz gs://BucketName
    Copy to Clipboard Toggle word wrap

4.8. Creating and configuring a base GCP instance
Copy link

To create and configure a Google Cloud Platform (GCP) instance that complies with GCP operating and security requirements, complete the following steps.

Procedure

  1. Create an image from the compressed file in the bucket. 

    $ gcloud compute images create BaseImageName --source-uri gs://BucketName/BaseImageName.tar.gz
    Copy to Clipboard Toggle word wrap

    Example: 

    [admin@localhost ~] $ gcloud compute images create rhel-76-server --source-uri gs://user-rhelha/rhel-server-76.tar.gz
Created [https://www.googleapis.com/compute/v1/projects/MyProject/global/images/rhel-server-76].
NAME            PROJECT                 FAMILY  DEPRECATED  STATUS
rhel-76-server  rhel-ha-testing-on-gcp                      READY
    Copy to Clipboard Toggle word wrap

  2. Create a template instance from the image. The minimum size required for a base RHEL instance is n1-standard-2. See gcloud compute instances create for additional configuration options. 

    $ gcloud compute instances create BaseInstanceName --can-ip-forward --machine-type n1-standard-2 --image BaseImageName --service-account ServiceAccountEmail
    Copy to Clipboard Toggle word wrap

    Example: 

    [admin@localhost ~] $ gcloud compute instances create rhel-76-server-base-instance --can-ip-forward --machine-type n1-standard-2 --image rhel-76-server --service-account account@project-name-on-gcp.iam.gserviceaccount.com
Created [https://www.googleapis.com/compute/v1/projects/rhel-ha-testing-on-gcp/zones/us-east1-b/instances/rhel-76-server-base-instance].
NAME   ZONE   MACHINE_TYPE   PREEMPTIBLE  INTERNAL_IP  EXTERNAL_IP     STATUS
rhel-76-server-base-instance  us-east1-bn1-standard-2          10.10.10.3   192.227.54.211  RUNNING
    Copy to Clipboard Toggle word wrap

  3. Connect to the instance with an SSH terminal session. 

    $ ssh root@PublicIPaddress
    Copy to Clipboard Toggle word wrap

  4. Update the RHEL software.

    1. Register with Red Hat Subscription Manager (RHSM).
    2. Enable a Subscription Pool ID.

    3. Disable all repositories. 

      # subscription-manager repos --disable=*
      Copy to Clipboard Toggle word wrap

    4. Enable the following repository. 

      # subscription-manager repos --enable=rhel-9-server-rpms
      Copy to Clipboard Toggle word wrap

    5. Run the dnf update command. 

      # dnf update -y
      Copy to Clipboard Toggle word wrap

  5. Install the GCP Linux Guest Environment on the running instance (in-place installation).

    See Install the guest environment in-place for instructions.

  6. Select the CentOS/RHEL option.
  7. Copy the command script and paste it at the command prompt to run the script immediately.

  8. Make the following configuration changes to the instance. These changes are based on GCP recommendations for custom images. See gcloudcompute images list for more information.

    1. Edit the /etc/chrony.conf file and remove all NTP servers.

    2. Add the following NTP server. 

      metadata.google.internal iburst Google NTP server
      Copy to Clipboard Toggle word wrap

    3. Remove any persistent network device rules. 

      # rm -f /etc/udev/rules.d/70-persistent-net.rules

# rm -f /etc/udev/rules.d/75-persistent-net-generator.rules
      Copy to Clipboard Toggle word wrap

    4. Set the network service to start automatically. 

      # chkconfig network on
      Copy to Clipboard Toggle word wrap

    5. Set the sshd service to start automatically. 

      # systemctl enable sshd
# systemctl is-enabled sshd
      Copy to Clipboard Toggle word wrap

    6. Set the time zone to UTC. 

      # ln -sf /usr/share/zoneinfo/UTC /etc/localtime
      Copy to Clipboard Toggle word wrap

    7. Optional: Edit the /etc/ssh/ssh_config file and add the following lines to the end of the file. This keeps your SSH session active during longer periods of inactivity. 

      # Server times out connections after several minutes of inactivity.
# Keep alive ssh connections by sending a packet every 7 minutes.
ServerAliveInterval 420
      Copy to Clipboard Toggle word wrap

    8. Edit the /etc/ssh/sshd_config file and make the following changes, if necessary. The ClientAliveInterval 420 setting is optional; this keeps your SSH session active during longer periods of inactivity. 

      PermitRootLogin no
PasswordAuthentication no
AllowTcpForwarding yes
X11Forwarding no
PermitTunnel no
# Compute times out connections after 10 minutes of inactivity.
# Keep ssh connections alive by sending a packet every 7 minutes.
ClientAliveInterval 420
      Copy to Clipboard Toggle word wrap

  9. Disable password access. 

    ssh_pwauth from 1 to 0.
ssh_pwauth: 0
    Copy to Clipboard Toggle word wrap
    Important

    Previously, you enabled password access to allow SSH session access to configure the instance. You must disable password access. All SSH session access must be passwordless.

  10. Unregister the instance from the subscription manager. 

    # subscription-manager unregister
    Copy to Clipboard Toggle word wrap

  11. Clean the shell history. Keep the instance running for the next procedure. 

    # export HISTSIZE=0
    Copy to Clipboard Toggle word wrap

4.9. Creating a snapshot image
Copy link

To preserve the configuration and disk data of a GCP HA instance, create a snapshot of it.

Procedure

  1. On the running instance, synchronize data to disk. 

    # sync
    Copy to Clipboard Toggle word wrap

  2. On your host system, create the snapshot. 

    $ gcloud compute disks snapshot InstanceName --snapshot-names SnapshotName
    Copy to Clipboard Toggle word wrap

  3. On your host system, create the configured image from the snapshot. 

    $ gcloud compute images create ConfiguredImageFromSnapshot --source-snapshot SnapshotName
    Copy to Clipboard Toggle word wrap

After you have configured an image from the snapshot, you can create a node template. Then, you can use this template to create all HA nodes.

Procedure

  1. Create an instance template. 

    $ gcloud compute instance-templates create InstanceTemplateName --can-ip-forward --machine-type n1-standard-2 --image ConfiguredImageFromSnapshot --service-account ServiceAccountEmailAddress
    Copy to Clipboard Toggle word wrap

    Example: 

    [admin@localhost ~] $ gcloud compute instance-templates create rhel-91-instance-template --can-ip-forward --machine-type n1-standard-2 --image rhel-91-gcp-image --service-account account@project-name-on-gcp.iam.gserviceaccount.com
Created [https://www.googleapis.com/compute/v1/projects/project-name-on-gcp/global/instanceTemplates/rhel-91-instance-template].
NAME  MACHINE_TYPE   PREEMPTIBLE  CREATION_TIMESTAMP
rhel-91-instance-template   n1-standard-2          2018-07-25T11:09:30.506-07:00
    Copy to Clipboard Toggle word wrap

  2. Create multiple nodes in one zone. 

    # gcloud compute instances create NodeName01 NodeName02 --source-instance-template InstanceTemplateName --zone RegionZone --network=NetworkName --subnet=SubnetName
    Copy to Clipboard Toggle word wrap

    Example: 

    [admin@localhost ~] $ gcloud compute instances create rhel81-node-01 rhel81-node-02 rhel81-node-03 --source-instance-template rhel-91-instance-template --zone us-west1-b --network=projectVPC --subnet=range0
Created [https://www.googleapis.com/compute/v1/projects/project-name-on-gcp/zones/us-west1-b/instances/rhel81-node-01].
Created [https://www.googleapis.com/compute/v1/projects/project-name-on-gcp/zones/us-west1-b/instances/rhel81-node-02].
Created [https://www.googleapis.com/compute/v1/projects/project-name-on-gcp/zones/us-west1-b/instances/rhel81-node-03].
NAME            ZONE        MACHINE_TYPE   PREEMPTIBLE  INTERNAL_IP  EXTERNAL_IP    STATUS
rhel81-node-01  us-west1-b  n1-standard-2               10.10.10.4   192.230.25.81   RUNNING
rhel81-node-02  us-west1-b  n1-standard-2               10.10.10.5   192.230.81.253  RUNNING
rhel81-node-03  us-east1-b  n1-standard-2               10.10.10.6   192.230.102.15  RUNNING
    Copy to Clipboard Toggle word wrap

4.11. Installing HA packages and agents
Copy link

On each of your nodes, you need to install the High Availability packages and agents to be able to configure a Red Hat High Availability cluster on Google Cloud Platform (GCP).

Procedure

  1. In the Google Cloud Console, select Compute Engine and then select VM instances.
  2. Select the instance, click the arrow next to SSH, and select the View gcloud command option.
  3. Paste this command at a command prompt for passwordless access to the instance.
  4. Enable sudo account access and register with Red Hat Subscription Manager.
  5. Enable a Subscription Pool ID.

  6. Disable all repositories. 

    # subscription-manager repos --disable=*
    Copy to Clipboard Toggle word wrap

  7. Enable the following repositories. 

    # subscription-manager repos --enable=rhel-9-server-rpms
# subscription-manager repos --enable=rhel-9-for-x86_64-highavailability-rpms
    Copy to Clipboard Toggle word wrap

  8. Install pcs pacemaker, the fence agents, and the resource agents. 

    # dnf install -y pcs pacemaker fence-agents-gce resource-agents-gcp
    Copy to Clipboard Toggle word wrap

  9. Update all packages. 

    # dnf update -y
    Copy to Clipboard Toggle word wrap

4.12. Configuring HA services
Copy link

On each of your nodes, configure the HA services.

Procedure

  1. The user hacluster was created during the pcs and pacemaker installation in the previous step. Create a password for the user hacluster on all cluster nodes. Use the same password for all nodes. 

    # passwd hacluster
    Copy to Clipboard Toggle word wrap

  2. If the firewalld service is installed, add the HA service. 

    # firewall-cmd --permanent --add-service=high-availability

# firewall-cmd --reload
    Copy to Clipboard Toggle word wrap

  3. Start the pcs service and enable it to start on boot. 

    # systemctl start pcsd.service

# systemctl enable pcsd.service

Created symlink from /etc/systemd/system/multi-user.target.wants/pcsd.service to /usr/lib/systemd/system/pcsd.service.
    Copy to Clipboard Toggle word wrap

Verification

  1. Ensure the pcsd service is running. 

    # systemctl status pcsd.service

pcsd.service - PCS GUI and remote configuration interface
Loaded: loaded (/usr/lib/systemd/system/pcsd.service; enabled; vendor preset: disabled)
Active: active (running) since Mon 2018-06-25 19:21:42 UTC; 15s ago
Docs: man:pcsd(8)
man:pcs(8)
Main PID: 5901 (pcsd)
CGroup: /system.slice/pcsd.service
└─5901 /usr/bin/ruby /usr/lib/pcsd/pcsd > /dev/null &
    Copy to Clipboard Toggle word wrap
  2. Edit the /etc/hosts file. Add RHEL host names and internal IP addresses for all nodes.

4.13. Creating a cluster
Copy link

To convert multiple nodes into a cluster, use the following steps.

Procedure

  1. On one of the nodes, authenticate the pcs user. Specify the name of each node in the cluster in the command. 

    # pcs host auth hostname1 hostname2 hostname3
Username: hacluster
Password:
hostname1: Authorized
hostname2: Authorized
hostname3: Authorized
    Copy to Clipboard Toggle word wrap

  2. Create the cluster. 

    # pcs cluster setup cluster-name hostname1 hostname2 hostname3
    Copy to Clipboard Toggle word wrap

Verification

  1. Run the following command to enable nodes to join the cluster automatically when started. 

    # pcs cluster enable --all
    Copy to Clipboard Toggle word wrap

  2. Start the cluster. 

    # pcs cluster start --all
    Copy to Clipboard Toggle word wrap

4.14. Creating a fencing device
Copy link

High Availability (HA) environments require a fencing device, which ensures that malfunctioning nodes are isolated and the cluster remains available if an outage occurs.

Note that for most default configurations, the GCP instance names and the RHEL host names are identical.

Procedure

  1. Obtain GCP instance names. Note that the output of the following command also shows the internal ID for the instance. 

    # fence_gce --zone us-west1-b --project=rhel-ha-on-gcp -o list
    Copy to Clipboard Toggle word wrap

    Example: 

    [root@rhel81-node-01 ~]# fence_gce --zone us-west1-b --project=rhel-ha-testing-on-gcp -o list

4435801234567893181,InstanceName-3
4081901234567896811,InstanceName-1
7173601234567893341,InstanceName-2
    Copy to Clipboard Toggle word wrap

  2. Create a fence device. 

    # pcs stonith create FenceDeviceName fence_gce zone=Region-Zone project=MyProject
    Copy to Clipboard Toggle word wrap
  3. To ensure immediate and complete fencing, disable ACPI Soft-Off on all cluster nodes. For information about disabling ACPI Soft-Off, see Disabling ACPI for use with integrated fence device.

Verification

  • Verify that the fence devices started. 

    # pcs status
    Copy to Clipboard Toggle word wrap

    Example: 

    [root@rhel81-node-01 ~]# pcs status

Cluster name: gcp-cluster
Stack: corosync
Current DC: rhel81-node-02 (version 1.1.18-11.el7_5.3-2b07d5c5a9) - partition with quorum
Last updated: Fri Jul 27 12:53:25 2018
Last change: Fri Jul 27 12:51:43 2018 by root via cibadmin on rhel81-node-01

3 nodes configured
3 resources configured

Online: [ rhel81-node-01 rhel81-node-02 rhel81-node-03 ]

Full list of resources:

us-west1-b-fence    (stonith:fence_gce):    Started rhel81-node-01

Daemon Status:
corosync: active/enabled
pacemaker: active/enabled
pcsd: active/enabled
    Copy to Clipboard Toggle word wrap

The gcp-vpc-move-vip resource agent attaches a secondary IP address (alias IP) to a running instance. This is a floating IP address that can be passed between different nodes in the cluster.

To show more information about this resource: 

# pcs resource describe gcp-vpc-move-vip
Copy to Clipboard Toggle word wrap

You can configure the resource agent to use a primary subnet address range or a secondary subnet address range:

Primary subnet address range

Complete the following steps to configure the resource for the primary VPC subnet.

Procedure

  1. Create the aliasip resource. Include an unused internal IP address. Include the CIDR block in the command. 

    # pcs resource create aliasip gcp-vpc-move-vip alias_ip=UnusedIPaddress/CIDRblock
    Copy to Clipboard Toggle word wrap

    Example: 

    [root@rhel81-node-01 ~]# pcs resource create aliasip gcp-vpc-move-vip alias_ip=10.10.10.200/32
    Copy to Clipboard Toggle word wrap

  2. Create an IPaddr2 resource for managing the IP on the node. 

    # pcs resource create vip IPaddr2 nic=interface ip=AliasIPaddress cidr_netmask=32
    Copy to Clipboard Toggle word wrap

    Example: 

    [root@rhel81-node-01 ~]# pcs resource create vip IPaddr2 nic=eth0 ip=10.10.10.200 cidr_netmask=32
    Copy to Clipboard Toggle word wrap

  3. Group the network resources under vipgrp. 

    # pcs resource group add vipgrp aliasip vip
    Copy to Clipboard Toggle word wrap

Verification

  1. Verify that the resources have started and are grouped under vipgrp. 

    # pcs status
    Copy to Clipboard Toggle word wrap

  2. Verify that the resource can move to a different node. 

    # pcs resource move vip Node
    Copy to Clipboard Toggle word wrap

    Example: 

    [root@rhel81-node-01 ~]# pcs resource move vip rhel81-node-03
    Copy to Clipboard Toggle word wrap

  3. Verify that the vip successfully started on a different node. 

    # pcs status
    Copy to Clipboard Toggle word wrap

Secondary subnet address range

Complete the following steps to configure the resource for a secondary subnet address range.

Prerequisites

Procedure

  1. Create a secondary subnet address range. 

    # gcloud compute networks subnets update SubnetName --region RegionName --add-secondary-ranges SecondarySubnetName=SecondarySubnetRange
    Copy to Clipboard Toggle word wrap

    Example: 

    # gcloud compute networks subnets update range0 --region us-west1 --add-secondary-ranges range1=10.10.20.0/24
    Copy to Clipboard Toggle word wrap

  2. Create the aliasip resource. Create an unused internal IP address in the secondary subnet address range. Include the CIDR block in the command. 

    # pcs resource create aliasip gcp-vpc-move-vip alias_ip=UnusedIPaddress/CIDRblock
    Copy to Clipboard Toggle word wrap

    Example: 

    [root@rhel81-node-01 ~]# pcs resource create aliasip gcp-vpc-move-vip alias_ip=10.10.20.200/32
    Copy to Clipboard Toggle word wrap

  3. Create an IPaddr2 resource for managing the IP on the node. 

    # pcs resource create vip IPaddr2 nic=interface ip=AliasIPaddress cidr_netmask=32
    Copy to Clipboard Toggle word wrap

    Example: 

    [root@rhel81-node-01 ~]# pcs resource create vip IPaddr2 nic=eth0 ip=10.10.20.200 cidr_netmask=32
    Copy to Clipboard Toggle word wrap

  4. Group the network resources under vipgrp. 

    # pcs resource group add vipgrp aliasip vip
    Copy to Clipboard Toggle word wrap

Verification

  1. Verify that the resources have started and are grouped under vipgrp. 

    # pcs status
    Copy to Clipboard Toggle word wrap

  2. Verify that the resource can move to a different node. 

    # pcs resource move vip Node
    Copy to Clipboard Toggle word wrap

    Example: 

    [root@rhel81-node-01 ~]# pcs resource move vip rhel81-node-03
    Copy to Clipboard Toggle word wrap

  3. Verify that the vip successfully started on a different node. 

    # pcs status
    Copy to Clipboard Toggle word wrap

Secure Boot is a mechanism in the Unified Extensible Firmware Interface (UEFI) specification to control the execution of programs at boot time. Secure Boot verifies digital signatures of the boot loader and its components at boot time, to ensure only trusted and authorized programs are executed, and also prevent unauthorized programs from loading. You can use this feature for both Google Cloud Platform (GCP) Red Hat Enterprise Linux images and custom RHEL images.

5.1. Types of RHEL images on GCP
Copy link

GCP Marketplace images
The GCP Marketplace provides a pre-configured Red Hat Enterprise Linux (RHEL) image that is tailored for specified use cases such as data processing, system management, and web development. This type of ready-to-use image reduces setup by minimizing manual installation and configuration time required for operating systems and software packages.
Custom RHEL image
A custom RHEL image offers flexibility to customers and organizations to build and deploy tailored environments that meet specific application and workflow requirements. By creating custom RHEL image, you can use RHEL instances that are pre-installed with necessary tools, configurations, and security policies. This customization aims at greater control over the infrastructure.

5.2. Understanding Secure Boot for RHEL on cloud
Copy link

Secure Boot is a feature of Unified Extensible Firmware Interface (UEFI) that ensures only trusted and digitally signed programs and components, such as the boot loader and kernel, are executed during boot time. Secure Boot verifies digital signatures against trusted keys stored in hardware, and aborts the boot process if it detects any components that have been tampered with or that are signed by untrusted entities. This prevents malicious software from compromising the operating system.

Secure Boot is an essential component for configuring a Confidential Virtual Machine (CVM), as it guarantees that only trusted entities are present in the boot chain. It provides authenticated access to specific device paths through defined interfaces, which ensures that only the latest configuration is used, and which also permanently overwrites earlier configurations. Additionally, when the Red Hat Enterprise Linux kernel boots with Secure Boot enabled, it enters the lockdown mode, which ensures that only kernel modules signed by a trusted vendor are loaded. Therefore, Secure Boot improves security of operating system boot sequence.

5.2.1. Components of Secure Boot
Copy link

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 is allowed to boot on the system. Additionally, all certificates from db are imported to the .platform keyring of the RHEL kernel. This feature allows you to 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 forbidden to boot on the system.
Note

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

5.2.2. Stages of Secure Boot for RHEL on Cloud
Copy link

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 is initialized 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) contains 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). UKI is signed by the corresponding certificate, Red Hat Secure Boot Signing 504 on the x86_64 architecture, which can be found in the redhat-sb-certs package. This certificate is signed by Red Hat Secure Boot CA, and thus passes the check.
  5. UKI add-ons: To use the UKI cmdline extensions, the RHEL kernel checks their signatures against db ,MOK, and certificates shipped with shim to ensure that the extensions are signed by either the operating system vendor RHEL or a user.

When the RHEL kernel boots in the Secure Boot mode, it enters 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, standard RHEL kernel modules, such as kernel-modules-core, kernel-modules, kernel-modules-extra are signed with an ephemeral key, which consists of private and public key. After the completion of each kernel build, the private key becomes obsolete to sign third-party modules. Certificates from db and MOK can be used for this purpose.

To ensure that your Red Hat Enterprise Linux instance on Google Cloud Platform (GCP) has secured operating system booting process, use Secure Boot. To configure a RHEL instance with Secure Boot support on GCP, launch a RHEL image from the GCP Marketplace, pre-configured with the Turn on Secure Boot option. The Turn on Secure Boot option enables support for the Unified Extensible Firmware Interface (UEFI) boot loader required for Secure Boot. Without UEFI, the Secure Boot feature does not work. By default, it has the Allowed Signature database (db) with Microsoft certificates.

Prerequisites

Procedure

  1. Launch a publicly available Red Hat Enterprise Linux instance from Google Cloud console.

  2. Install the keyutils package: 

    $ dnf install keyutils
    Copy to Clipboard Toggle word wrap

  3. Enable the Turn on Secure Boot option on the RHEL GCP instance:

    Secure Boot for RHEL GCP instance
    View larger image
    Secure Boot for RHEL GCP instance

Verification

  1. Verify if Secure Boot is enabled: 

    $ mokutil --sb-state

SecureBoot enabled
    Copy to Clipboard Toggle word wrap

  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
    Copy to Clipboard Toggle word wrap

To ensure that your Red Hat Enterprise Linux instance on Google Cloud Platform (GCP) has secured operating system booting process, use Secure Boot. When a custom RHEL GCP image is registered, the image consists of pre-stored Unified Extensible Firmware Interface (UEFI) variables for Secure Boot. This enables all the instances launched from the RHEL images to use the Secure Boot mechanism with the required variables on the first boot. You can configure a RHEL instance by including a custom certificate into the SecureBoot DB, so that you can sign custom artifacts, such as third party kernel modules and Unified Kernel Image (UKI) add-ons.

Prerequisites

  1. You have created and uploaded a RHEL GCP image. For details, see Uploading images to GCP.

  2. You have installed the following packages:

    • python3
    • efivar
    • keyutils
    • openssl
    • python3-virt-firmware
  3. You have installed the google-cloud-cli utility. For details, see installing gcloud CLI on RHEL.

Procedure

  1. Create a new random Universally Unique Identifier (UUID) and store it in a system generated random text file: 

    $ uuidgen --random > GUID.txt
    Copy to Clipboard Toggle word wrap

  2. Generate a new RSA private key PK.key and a self-signed X.509 certificate PK.cer for the Platform Key database: 

    $ openssl req -quiet \
-newkey rsa:4096 \
-nodes -keyout PK.key \
-new -x509 -sha256 \
-days 3650 \
-subj "/CN=Platform key/" \
-outform DER \
-out PK.cer
    Copy to Clipboard Toggle word wrap

    The openssl utility generates a common name Platform key for the certificate by setting output format to Distinguished Encoding Rules (DER). DER is a standardized binary format for data encoding.

  3. Generate a new RSA private key KEK.key and a self-signed X.509 certificate KEK.cer for the Key Exchange Key database: 

    $ openssl req -quiet \
-newkey rsa:4096 \
-nodes -keyout KEK.key \
-new -x509 -sha256 \
-days 3650 \
-subj "/CN=Key Exchange Key/" \
-outform DER \
-out KEK.cer
    Copy to Clipboard Toggle word wrap

  4. 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
    Copy to Clipboard Toggle word wrap

  5. Download the Microsoft certificate: 

    $ wget https://go.microsoft.com/fwlink/p/?linkid=321194 --user-agent="Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36" -O MicCorUEFCA2011_2011-06-27.crt
    Copy to Clipboard Toggle word wrap

  6. Download the updated forbidden signatures (dbx) UEFI Revocation List File for 64 bit system: 

    $ wget https://uefi.org/sites/default/files/resources/x64_DBXUpdate.bin
    Copy to Clipboard Toggle word wrap

  7. 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=PK.cer \
--key-exchange-key-file=KEK.cer \
--signature-database-file=custom_db.cer,MicCorUEFCA2011_2011-06-27.crt \
--forbidden-database-file x64_DBXUpdate.bin \
--guest-os-features="UEFI_COMPATIBLE"
    Copy to Clipboard Toggle word wrap

  8. 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 GCP instance
    View larger image
    Secure Boot for RHEL GCP instance

Verification

  1. Verify if Secure Boot is enabled: 

    $ mokutil --sb-state
SecureBoot enabled
    Copy to Clipboard Toggle word wrap

  2. Verify the kernel keyring for the custom certificate: 

    $ sudo keyctl list %:.platform
...
757453569: ---lswrv     0     0 asymmetric: Signature Database key: f064979641c24e1b935e402bdbc3d5c4672a1acc
...
    Copy to Clipboard Toggle word wrap

Legal Notice
Copy link

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2025 Red Hat