Public Cloud Guide

3.1 Registering instances #

Like other SUSE products, SUSE Linux Enterprise in public clouds has to be registered to receive updates. There are different ways to register, depending on the image flavor chosen for the instance.

PAYG instances are registered automatically against the SUSE-operated update infrastructure in the cloud framework region, or a geographically close region. The guestregister.service manages the registration on first boot.
Important: Do not register PAYG instances with the SUSE Customer Center
Registering PAYG instances with the SUSE Customer Center or your own RMT server will create conflicts that are not easily solved. Only register BYOS instances. PAYG instances are automatically registered against the correct update server.
BYOS instances have to be registered manually with your SUSE registration key. You can register with the cloud framework's SUSE update servers, the SUSE Customer Center, or your own SUSE Multi-Linux Manager or RMT infrastructure.

There are two different ways to register BYOS instances:

Any BYOS instance can be registered with the SUSE Customer Center or your own SUSE Multi-Linux Manager or RMT infrastructure using SUSEConnect. Refer to Section 3.1.2, “Register with SUSEConnect” for instructions.
BYOS instances with cloud-regionsrv-client version 9.3.0 or higher can be registered with the cloud framework's SUSE update servers using registercloudguest. Using the cloud framework's update servers will result in faster package downloads. Registrations are forwarded from the update server to the SUSE Customer Center, so your cloud instances show up in your SUSE account and count against the system count of your subscription. Refer to Section 3.1.1, “Register with registercloudguest” for instructions.
Important: registercloudguest limitations
Not all products and flavors can be registered with registercloudguest.
- Container host (chost) images are optimized for container workloads and contain only a few packages outside of the bare minimum to make containers run. These images do not contain registercloudguest, but you can register instances with the SUSE Customer Center first, install the necessary packages and then register with the SUSE-operated update infrastructure in the cloud framework region. Refer to Procedure 3.1, “Switching from SUSEConnect to registercloudguest” for instructions.
- SUSE Linux Enterprise Micro (sle-micro) 5.1 and 5.2 images do not contain registercloudguest. To register an instance, use the command transactional-update register. Refer to the SUSE Linux Enterprise Micro Administration Guide for more information. Images of SLE Micro 5.3 and later versions include registercloudguest and can be registered as described in Section 3.1.1, “Register with registercloudguest”.
- SUSE Multi-Linux Manager (suse-manager) can only be registered with the SUSE Customer Center.

In summary, use registercloudguest to register with the local cloud update infrastructure to benefit from faster downloads. Use SUSEConnect to register with SUSE Customer Center or your own SUSE Multi-Linux Manager or RMT infrastructure.

3.1.1 Register with `registercloudguest` #

To register a BYOS instance with registercloudguest, run:

# registercloudguest -r REGISTRATION_CODE  -e EMAIL_ADDRESS

Replace REGISTRATION_CODE with a valid registration code. Replace EMAIL_ADDRESS with the e-mail address associated with the SUSE account you or your organization uses to manage subscriptions.

BYOS instances created from images with a datestamp of 20220103 or later contain all required packages. For BYOS instances created from images with a date stamp prior to 20220103, perform the following steps:

Procedure 3.1: Switching from SUSEConnect to registercloudguest #

Check if the cloud-regionsrv-client package is installed:
```
# rpm -q cloud-regionsrv-client
```
If the package is not installed or older than version 9.3.0, install or update it.
For instances created from images with a date stamp prior to 20220103, you first have to enable the Public Cloud Module. For SUSE Linux Enterprise 15 SP4, run:
```
# SUSEConnect -p sle-module-public-cloud/15.4/x86_64
```
For other versions or a complete list of modules and their product identifiers, run SUSEConnect --list-extensions.
Install cloud-regionsrv-client. Depending on your cloud framework, you will need some additional packages.
- For Amazon EC2 run:
```
# zypper in cloud-regionsrv-client cloud-regionsrv-client-plugin-ec2 \
 regionServiceClientConfigEC2
```
- For Microsoft Azure run:
```
# zypper in cloud-regionsrv-client cloud-regionsrv-client-plugin-azure \
 regionServiceClientConfigAzure
```
- For Google Compute Engine run:
```
# zypper in cloud-regionsrv-client cloud-regionsrv-client-plugin-gce \
 regionServiceClientConfigGCE
```
Disconnect your instance from the SUSE Customer Center:
```
# registercloudguest --clean
```
Do not use SUSEConnect -d; it will no longer work.
Connect the instance to the SUSE update infrastructure in the public cloud. Replace REGISTRATION_CODE with a valid registration code. Replace EMAIL_ADDRESS with the e-mail address associated with the SUSE account you or your organization uses to manage subscriptions.
```
# registercloudguest -r REGISTRATION_CODE  -e EMAIL_ADDRESS
```
This will only register the base product and any recommended products. For instances created from images with a datestamp later than 20220103, it will also set up the repositories for the Public Cloud Module.

3.1.2 Register with `SUSEConnect` #

To register a BYOS instance with SUSEConnect, run:

# SUSEConnect -r REGISTRATION_CODE -e EMAIL_ADDRESS

Replace REGISTRATION_CODE with a valid registration code. Replace EMAIL_ADDRESS with the e-mail address associated with the SUSE account you or your organization uses to manage subscriptions.

To register with your own registration server, also provide its URL:

# SUSEConnect -r REGISTRATION_CODE -e EMAIL_ADDRESS --url URL

If the instance was already registered with registercloudguest, perform the following steps:

Procedure 3.2: Switching from registercloudguest to SUSEConnect #

Disconnect your instance from the SUSE-operated update infrastructure in the cloud framework:
```
# registercloudguest --clean
```
Uninstall the cloud-regionsrv-client package and its dependencies:
```
# zypper rm -u cloud-regionsrv-client
```

Clean up the registration status:

# SUSEConnect --cleanup --url https://scc.suse.com

Register the instance with SUSEConnect.
- To connect the instance to the SUSE Customer Center, run:
```
# SUSEConnect -r REGISTRATION_CODE -e EMAIL_ADDRESS
```
- To connect the instance to the your own registration server, run:
```
# SUSEConnect -r REGISTRATION_CODE -e EMAIL_ADDRESS --url URL
```

3.2 Deregister instances #

If you are to decommission an instance, remember to deregister it before termination. This will ensure that the system gets removed from the SUSE Customer Center and is no longer counted against your subscription.

Run SUSEConnect --status-text to check the registration status.
If the system is registered, check if the file /var/log/cloudregister exists. This usually indicates the system was registered with registercloudguest.
Deregister the system:
- If a system was registered with registercloudguest, run:
```
# registercloudguest --clean
```
- If a system was registered with SUSEConnect, run:
```
# SUSEConnect -d
```
  If this does not work, make sure the package cloud-regionsrv-client is not installed. It may have been installed after the system was registered.

3.3 Enabling LTSS #

Long Term Service Pack Support (LTSS) extends the lifecycle of SUSE Linux Enterprise. It is available as an extension. For more information about LTSS, refer to https://www.suse.com/products/long-term-service-pack-support/.

Note: LTSS subscriptions are version-specific

LTSS subscriptions are version-specific. If you have a subscription for SLES 15 SP4, you cannot use that registration code to register LTSS on a 15 SP3 image. Make sure to use the correct registration code for your instance and upgrade it if necessary.

Note: Microsoft Azure basic images are not eligible for LTSS

Microsoft Azure also offers a basic PAYG image that only includes updates. Instances created from this image are not eligible for LTSS.

3.3.1 LTSS on BYOS #

If you do not have an LTSS subscription for your BYOS instance, contact a SUSE representative or visit https://www.suse.com/how-to-buy for purchase options.

To enable the LTSS extension, perform the following steps:

Log in to the SUSE Customer Center to look up your LTSS registration code.
Log in to your instance and make sure your system is registered:
```
> sudo SUSEConnect --status-text
```
If the system is not yet registered, register it (see Section 3.1, “Registering instances”).

Check if the LTSS extension is available for your system. For SUSE Linux Enterprise 15 SP3, it looks like this:

> sudo SUSEConnect --list-extensions | grep LTSS
      SUSE Linux Enterprise Server LTSS 15 SP3 x86_64
      Activate with: SUSEConnect -p SLES-LTSS/15.3/x86_64 -r ADDITIONAL REGCODE

Activate the module as instructed:

> sudo SUSEConnect -p SLES-LTSS/15.3/x86_64 -r LTSS_REGISTRATION_CODE

3.3.2 LTSS on PAYG #

LTSS subscriptions for PAYG can be transacted through a private offer on the CSPs market place or via direct transaction with SUSE. Reach out to cloudsales@suse.com to work out the commercial details. You will receive a subscription and access to the SUSE Customer Center). With your subscription, you can activate a registration code for LTSS.

Tip: Existing LTSS subscriptions

If you already have an LTSS subscription that you are using in your data center, it will work in the cloud just fine. You can deregister a system in your data center and move that use of your LTSS subscription to an instance in the cloud.

To enable the LTSS extension, perform the following steps:

Log in to the SUSE Customer Center to activate a registration code. Note that LTSS subscriptions are version-specific. If you have a subscription for SLES 15 SP4, you cannot use that registration code to register LTSS on a 15 SP3 image. Make sure to activate the LTSS registration code for the correct version and service pack (SP) of your instance!
Log in to your instance and make sure your system is registered with a subscription that is eligible for LTSS. If the system is not yet registered, register it (see Section 3.1, “Registering instances”).
Update cloud-regionsrv-client:
```
> sudo zypper up cloud-regionsrv-client
```
You need at least version 10.3.4 of the package.

Register the LTSS extension with the registration code you activated in the SUSE Customer Center:

> sudo registercloudguset -r LTSS_REGISTRATION_CODE
Running LTSS registration...this takes a little longer
LTSS registration succeeded

3.4 Hardening instances #

To improve overall security, SUSE provides hardened images of some products. The images are hardened using OpenSCAP, a collection of open source tools that implement the Security Content Automation Protocol (SCAP) maintained by the National Institute of Standards and Technology (NIST). OpenSCAP supports automated configuration, vulnerability and patch checking, technical control compliance activities, and security measurement.

To harden a system, OpenSCAP uses security rules that define certain security measures. Multiple rules can be combined into profiles. For more information, refer to the OpenSCAP documentation at https://www.open-scap.org/resources/documentation/.

3.4.1 Pre-hardening #

Hardened images are pre-hardened to the extent they can safely be hardened without causing problems in public cloud frameworks. Certain rules can only be applied after instance creation, for example:

Rules that require having passwords set up. Passwords would have to be public if configured during the image build. This would defeat the purpose of a secret password.
Rules that affect the network configuration. Networking is set up during instance creation, therefore it is not possible to limit access during image build.
Rules for custom partitioning. SUSE's public cloud images are partitioned to meet the requirements of the framework in which they are released. If your system needs to meet standards that require separate file systems for given directories, we recommend that you build your own images and use LVM or move those directories onto attached disks to get the strictest data separation possible.
Rules to remove packages. SUSE's public cloud images cater to a wide range of use cases. Even if the number of packages is limited, it is impossible to determine what packages an instance requires.

3.4.2 Available OpenSCAP profiles #

After instance creation, you can use the installed openscap packages to complete the hardening process using any of the following profiles:

Standard (standard.profile): Basic OpenSCAP system security standard.
CIS Server Level 2 (cis.profile): The Center for Internet Security Server Level 2 profile is considered to be “defense in depth” and is intended for environments where security is paramount. The recommendations associated with this profile can have an adverse effect on your organization if not implemented appropriately or without due care. For more information, refer to https://www.cisecurity.org.
Department of Defense STIG (stig.profile): The Defense Information Systems Agency publishes Security Technical Implementation Guides (STIGs) for the Department of Defense. The STIG profile replaces the previous CIS Level 3 profile and provides all recommendations that are STIG-specific. Overlap of recommendations from other profiles, i.e. CIS Level 1 and Level 2, are present in the STIG profile as applicable. For more information, refer to https://public.cyber.mil/stigs/.
HIPAA Security Rule (hipaa.profile): In response to the Health Insurance Portability and Accountability Act (HIPAA) of 1996, the U.S. Department of Health and Human Services developed Security Standards for the Protection of Electronic Protected Health Information, commonly known as the HIPAA Security Rule. It establishes national standards to protect individuals' electronic personal health information (e-PHI) that is created, received, used, or maintained by a covered entity. For more information, refer to https://www.hhs.gov/hipaa/for-professionals/security/index.html.
Payment Card Industry Data Security Standard (pci-dss.profile): The Payment Card Industry Data Security Standard (PCI DSS) is a set of requirements to guide merchants to protect cardholder data. It is maintained by the PCI Security Standards Council (SSC) that was founded by all five major credit card brands Visa, MasterCard, American Express, Discover, and JCB. For more information, refer to https://www.pcisecuritystandards.org/document_library.

All profile files are available in the ComplianceAsCode repository.

For a complete list of rules that have been applied during pre-hardening, refer to pcs-hardening.profile. This profile is a combination of the STIG and CIS profiles minus rules that can only be applied after instance creation.

Images of SUSE Linux Enterprise Server for SAP applications are hardened using a modified version of the profile called pcs-hardening-sap.profile. Users may need to make additional modifications to the system configuration depending on individual application needs.

Important: Recommended profiles

SUSE recommends using either the CIS or the STIG profile. You can use other profiles at your own discretion.

3.4.3 Hardening instances with OpenSCAP #

To evaluate an instance, you can run:

> sudo oscap xccdf eval \
--profile stig1 \
--results /tmp/results.xml2 \
--report /tmp/report.html3 \
--stig-viewer /tmp/stigviewer.xml4 \
/usr/share/xml/scap/ssg/content/ssg-sle15-ds-1.2.xml5

1	Specifies the profile to use, e.g. `stig` or `cis`.
2	Saves the results of the evaluation to `/tmp/results.xml`
3	Generates a HTML report called `/tmp/report.html` in addition to the results in XML.
4	Saves the results to `/tmp/stigviewer.xml`, which can be imported into the `DISA STIG Viewer`. Refer to https://public.cyber.mil/stigs/srg-stig-tools/ for information about DISA STIG Viewer.
5	`Scap Security Guide` (SSG) policy file in the `datastream` (ds) format. Make sure to select the correct version for your instance. To list all available policies, run: `ls -1 /usr/share/xml/scap/ssg/content/ssg-*-ds.xml`.For more information about a particular policy, run `oscap info` on the file.

The evaluation process usually takes a few minutes, depending on the number of selected rules.

To remediate an instance, add the --remediate parameter:

> sudo oscap xccdf eval --remediate\
--profile stig \
--results /tmp/results.xml \
--report /tmp/report.html \
--stig-viewer /tmp/stigviewer.xml \
/usr/share/xml/scap/ssg/content/ssg-sle15-ds-1.2.xml

3.4.4 More information #

For more information on how to harden your SUSE Linux Enterprise system with OpenSCAP, refer to the article Hardening SUSE Linux Enterprise with OpenSCAP. For general information on OpenSCAP, refer to the SCAP Security Guide.

3.5 Confidential computing on AWS #

Confidential computing is a security technology that protects data while it is actively being processed, or in use. It addresses the “data in use” gap in traditional security models, which typically focus on “data at rest” (encryption on disk) and “data in transit” (encryption over the network).

In conventional environments, data in use can be exposed to threats from privileged insiders, compromised hypervisors, or advanced malware capable of reading system memory. Confidential computing addresses this attack vector by placing workloads inside a hardware-protected Trusted Execution Environment (TEE). The memory part of the TEE is encrypted and strictly access controlled ensuring that neither cloud service providers, system administrators, or system-level software can view or modify data in use.

3.5.1 Trusted Execution Environment (TEE) #

At the heart of confidential computing is the trusted execution environment (TEE). A TEE is defined by three core technological pillars:

Isolation: A hardware-based, isolated area within a processor. It ensures that only authorized code can access the data inside, protecting it from other processes, the operating system, and the hypervisor.
Invisibility: Data remains encrypted in memory and is only decrypted inside the CPU's TEE. Even with physical access to the memory, the data is unreadable.
Attestation: A cryptographic proof that verifies the hardware and software are genuine and correctly configured before any data is released to the environment.

3.5.2 Implementation on AWS #

AWS implements the TEE concepts through a combination of Nitro Trusted Platform Module (NitroTPM) technology, specialized OS images, and Nitro Enclaves.

Isolation on AWS

Isolation is achieved using images that provide an overlay-based read-only system. This system is verified at boot time by dm-verity, which checks all rootfs blocks. In production, instances from these images are not expected to be remotely accessible to minimize the attack surface.

Invisibility on AWS

While the base instance runs in overlayfs mode (writing to memory only), this memory area is not encrypted. To ensure application memory cannot be accessed, the workload must run as a Nitro Enclave.

Nitro Enclaves protect and encrypt the memory area, making it invisible to the host OS and hypervisor. Communication with the enclave is strictly limited to a local vsock connection.

Attestation on AWS

The image boots via a PCR-measured Unified Kernel Image (UKI) containing the kernel, initrd, and bootloader. The Platform Configuration Register (PCR) values can be:

Checked against an attestation document.
Used as an AWS Key Management Service (KMS) key policy to block operations if there is a key mismatch, ensuring only "known good" software can run.

3.5.3 Deploying attestable images #

To start, you need an attestable image. SUSE provides a SUSE Linux Enterprise Server (SLES) image for AWS for demonstration purposes. This image contains the necessary configurations for Nitro TPM and an example enclave. You can download the image from the Open Build Service at https://download.opensuse.org/repositories/Virtualization:/Appliances:/Images:/Testing_x86:/leap/images_sles/kiwi-test-image-aws-isolated-compute.x86_64.raw.xz.
The image is built with KIWI NG. To build your own attestable image, refer to Building Linux System Appliances and the image description files of the demonstration image at https://github.com/OSInside/kiwi/tree/main/build-tests/x86/leap/test-image-aws-isolated-compute.
Upload the attestable image to Amazon EC2 with ec2uploadimg or a custom upload script. ec2uploadimg is available from the Open Build Service at https://build.opensuse.org/projects/Virtualization:Appliances:Images:Testing_x86:leap/packages/test-image-aws-isolated-compute/files/ec2-upload.
Important
When uploading the AMI, you must enable TPM 2.0 support and set the EFI boot mode to UEFI.
Before launching the instance, download the precomputed PCR measurements from https://download.opensuse.org/repositories/Virtualization:/Appliances:/Images:/Testing_x86:/leap/images_sles/pcr_measurements.json.
In this file, you will find the expected NitroTPM PCR 4, 7, and 12 values based on the UKI. They serve as the baseline for verifying the integrity of your instance.
In the EC2 launch wizard, select an instance type that supports Nitro TPM and Enclaves such as m5.xlarge. In the Advanced Details section, ensure that Enclave support is explicitly enabled.
Log in to the instance and generate an attestation document
```
> nitro-tpm-attest > /tmp/nitro.attest.cbor
```
View the attestation document with:
```
> show-nitrotpm-pcrs
```
Compare the values match pcr_measurements.json.

If the values match, you have verified that:

The TEE matches the expected image uploaded to EC2.
The rootfs is clean, immutable, and verified by dm-verity.

3.5.4 Managing the enclave workload #

Enclaves are packaged as AWS enclave image files (.eif). The example enclave is stored in the TEE's /data directory and is designed to return the PCR values from the attestation document when queried via vsock. This allows you to verify that the enclave's integrity matches the expected values. This workload in itself is not meant to be a real-world application but serves as a demonstration of how to build and run an enclave that can attest its integrity.

Just like attestable images, enclaves can be built with KIWI NG. To build your own enclave, refer to the image description files of the example at https://github.com/OSInside/kiwi/tree/main/build-tests/x86/leap/test-image-nitro-enclave and the build configuration in the Open Build Service at https://build.opensuse.org/package/show/Virtualization:Appliances:Images:Testing_x86:leap/test-image-nitro-enclave.

3.5.4.1 Running the enclave #

Use the nitro-cli tool to launch your workload:

> pushd /data
> nitro-cli run-enclave \
  --eif-path kiwi-test-image-nitro-enclave.x86_64-1.1.1.eif  \
  --cpu-count 2 \
  --memory 2048
> nitro-cli describe-enclaves

3.5.4.2 Enclave attestation #

To verify the enclave's integrity, connect to it via vsock and instruct it to return the PCRs from the enclave's attestation document:

> vsock_client Enclave-CID

Matching the enclave's PCRs with the output of describe-enclaves confirms:

The enclave integrity matches the image.
All memory used by the enclave is encrypted and isolated.