Applies to SUSE Linux Enterprise

3 Managing cloud instances #

SUSE Linux Enterprise in public clouds is managed almost like on bare metal or in virtual environments. Learn about what is different in the cloud.

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 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 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 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 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 regionServiceCertsEC2
```
- For Microsoft Azure run:
```
# zypper in cloud-regionsrv-client cloud-regionsrv-client-plugin-azure \
 regionServiceClientConfigAzure regionServiceCertsAzure
```
- For Google Compute Engine run:
```
# zypper in cloud-regionsrv-client cloud-regionsrv-client-plugin-gce \
 regionServiceClientConfigGCE regionServiceCertsGCE
```
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/guestregister 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 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.3.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.3.2 Avialable 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.3.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.3.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.