Red Hat Enterprise Linux Software Certification Policy Guide

Red Hat Software Suite 7.18

For Use with Red Hat Enterprise Linux Software Certification Policy Guide

Red Hat Customer Content Services

Abstract

This document describes the technical and operational certification requirements for Red Hat Partners who want to offer their own non-containerized software for use on systems and cloud environments running Red Hat Enterprise Linux (RHEL) 8. Last updated: Oct 12, 2020.

Chapter 1. Introduction

1.1. Audience

Independent Software Vendors (ISV) who want to understand the requirements and obligations of certifying non-containerized software for use on Red Hat Enterprise Linux (RHEL) 8.

1.2. Software certification process overview

The software certification process includes three primary steps- 1) Certification on-boarding, 2) Certification testing, and 3) Publishing a Red Hat Ecosystem Catalog certified listing.

Red Hat Enterprise Linux Software Certification Workflow Guide must be followed as it covers the step by step process of the following high level procedure summary.

High level procedure summary

  1. Certification on-boarding

    1. Partner joins the Red Hat Connect for Technology Partner Program.
    2. Partner accesses the Red Hat Enterprise Linux Zone.
    3. Partner adds a product to be certified.
    4. Partner joins TSANet.org joint support program.
  2. Certification testing

    1. Partner creates a certification project.
    2. Partner completes the certification checklist and the application profile.

      1. Partner confirms the membership in TSANet.org.
      2. Partner provides evidence that the product is a commercially supported General Available (GA) release.
    3. Partner downloads the certification test suite.
    4. Partner executes the certification test suite.
    5. Partner submits the certification test suite results.
    6. Red Hat reviews, rules and provides feedback on the test suite results.
  3. Publishing a Red Hat Ecosystem Catalog certified listing

    1. Red Hat will authorize the listing once the certification is completed.
Important

The Red Hat Enterprise Linux software certification does not conduct any explicit testing of the Partner’s product, in how it functions or performs outside of its impact on the Red Hat Enterprise Linux (RHEL) platform on which it was installed and executed.

Any and all aspects of the certification candidate product’s quality assurance remains the Partner’s sole responsibility.

Chapter 2. Creating value for our joint customers

The certification process includes a series of tests that provide your Red Hat customers an assurance that they will have a consistent experience when your application is deployed across different Red Hat Enterprise Linux (RHEL) 8 environments and footprints.

Partners are expected to have entered into certifications in good faith and for the interest of our joint customers. Customers will also have the confidence that their deployments are jointly supported by Red Hat and your organization ensuring the customer’s experience comes with the highest level of support.

Chapter 3. Certification lifecycle

A Red Hat Enterprise Linux software certification covers a range of Red Hat Enterprise Linux (RHEL) 8 minor versions and RHEL application minor versions on a single architecture and is expected to be maintained once certified to ensure the continued success of our joint customers.

3.1. Red Hat Certification test suite life cycle and policy update

Red Hat supports previous versions of the Red Hat Certification test suite and workflow for a maximum period of 90 days from the release date of the current version.

At the end of the 90 days period, test logs and results generated using the previous versions are automatically rejected and partners are expected to regenerate the test logs and results using the latest tooling and workflow.

The latest version of the certification tooling and workflow is available via the Red Hat Software Download Center.

3.2. Red Hat Enterprise Linux 8 versions

A Red Hat Enterprise Linux (RHEL) 8 software certification is granted on a specific RHEL 8 minor version and is valid for each subsequent minor release of RHEL 8 when the compatibility guidelines are followed.

The compatibility guidelines are documented in the Red Hat Enterprise Linux 8: Application Compatibility Guide. Red Hat recommends Partners to retest their application with each new minor versions of RHEL 8.

Additional resources

3.3. Vendor’s product versions

A Red Hat Enterprise Linux (RHEL) 8 software certification is awarded for a given major release of the application. Minor releases of the software are expected to be retested for any regressions that would negatively impact the certification but are not required to be re-certified.

Partners are encouraged to provide customers a matrix of supported and tested application minor releases to RHEL 8 minor releases for clarity.

A new certification is required for major versions of the application. Partners are expected to recertify new major versions of their application either as a new version of the existing product or as a new product entry. It is the partner’s responsibility to decide which releases of their product are major versus which releases are minor.

3.4. Architecture

A Red Hat Enterprise Linux (RHEL) 8 software certification is architecture specific and does not carry over to any other architecture. Partners are required to certify on each architecture of RHEL 8 that their application supports.

3.5. Catalog entries

A Red Hat Enterprise Linux (RHEL) 8 software certification is expected to remain listed in the catalog until the end of Red Hat service and support for RHEL 8. However, Red Hat reserves the right to remove a catalog entry.

Chapter 4. Test environment policies

A proper test environment supports execution of your software on a supported platform running Red Hat Enterprise Linux (RHEL) 8. Red Hat recommends the platform should already be certified for RHEL 8 to avoid discovering problems with uncertified platforms and unsupported hardware. Certified platforms can be found in the Red Hat Ecosystem Catalog.

The platform may be any of the four supported footprints - bare metal, virtual machine, private cloud, or public cloud. It is recommended to follow the platform providers procedures for deploying RHEL 8 to avoid platform issues and ensure a successful certification.

4.1. Red Hat Certification tests overview

The Red Hat Enterprise software certification includes three primary tests - selfcheck, supportable, and system report with a series of subtests and checks. A certification may exit with one of the following statuses:

  • Pass: All the subtests have passed and no further action is required.
  • Fail: A critical subtest or check has not succeeded and requires a change before a certification can be achieved.
  • Review: Additional detailed review is required by Red Hat to determine the status.
  • Warn: One or more subtests did not follow best practices and require further action. However, the certification will succeed.

Partners are recommended to review the output of all tests, perform appropriate actions, and re-run the test as appropriate.

Chapter 5. Testing requirements

The testing requirements include execution of the redhat-certification-software test suite, including all of the tests described in the following sections. The execution of the test suite happens in a single sequential session orchestrated by the redhat-certification application. The test execution is to be conducted while the software to be certified is running or the results will be rejected.

This test run provides a certification test result in a single file, which is provided to Red Hat. The file includes results for the following tests:

  • rhcert/self check,
  • rpm validation tests,
  • sosreport, and
  • supportability tests.

5.1. Red Hat certification self check (rhcert/selfcheck)

The Red Hat Certification self check test also known as rhcert/selfcheck confirms that all the software packages required in the certification process are installed and that they have not been altered. This ensures that the test environment is ready for the certification process and that all the installed certification software packages are supportable.

Success Criteria

The test environment includes all the packages required in the certification process and the packages have not been modified.

5.2. RPM test

The RPM test is also known as software/rpm. The test validates that a packaged rpm software under test adheres to Red Hat’s best practices for RPM packaging. If the software product under test is packaged as an RPM the subsequent subtests will be executed.

It is not a requirement for Red Hat Enterprise Linux software certification to package as an RPM, nor that the packaged RPM subtests should undergo PASS results.

The software/rpm test includes the following subtests:

5.2.1. RPM provenance

The RPM provenance subtest verifies if RPM packaged software under test and its RPM packaged dependencies have identifiable provenance in accordance with Red Hat’s best practices for RPM packaging.

Success Criteria

  • Non Red Hat packages are identified as the software product under test or dependencies of the software product under test.
  • Files are tracked within the packages

5.2.2. RPM version handling

The RPM version handling subtest verifies if the RPM packaged software product under test and it’s RPM packaged dependencies are versioned in accordance with Red Hat’s best practices for RPM packaging.

Success Criteria

  • Packages and changes to packages are versioned

5.2.3. RPM dependency tracking

The RPM dependency tracking subtest verifies if the RPM packaged software product under test and its dependencies are tracked with validity in accordance with Red Hat’s best practices for RPM dependency tracking.

  • Success Criteria*
  • All dependencies are validly tracked.

5.3. Supportability

The Supportability tests, also known as software/supportable, ensures that the Red Hat Enterprise Linux (RHEL) remains supportable by Red Hat with the software to be certified installed and running.

The software/supportable tests include the following subtests:

5.3.1. Log versions

The Log versions subtest verifies the version of Red Hat Enterprise Linux (RHEL) installed on the image.

5.3.2. Kernel

The Kernel subtest confirms the kernel that the image is running is from Red Hat, is appropriate and supports the RHEL version that is undergoing certification, and has not been modified. The kernel version may be the original General Availability (GA) version or any subsequent kernel errata released for the RHEL major + minor release.

The subtest also ensures that the kernel is not tainted when running in the environment.

Success Criteria

  • The running kernel is a Red Hat kernel.
  • The running kernel is released by Red Hat for use with RHEL 8.
  • The running kernel is not tainted.

5.3.3. Kernel modules

The Kernel modules subtest confirms the loaded kernel modules are from Red Hat, either from the running kernel’s package or a Red Hat Driver Update. The kernel module subtest also ensures the kernel modules do not identify as a Technology Preview and does not identify as having triggered a slow path in the kernel.

Success Criteria

  • The kernel modules are from Red Hat and supported.

5.3.4. Hardware Health

The Hardware Health subtest checks the system’s health by testing if the hardware is supported, meets the requirements, and has any known hardware vulnerabilities. The subtest does the following:

  • Checks that the Red Hat Enterprise Linux (RHEL) kernel does not identify hardware as unsupported. When the kernel identifies unsupported hardware, it will display an unsupported hardware message in the system logs and/or trigger an unsupported kernel taint. This subtest prevents customers from possible production risks which may arise from running Red Hat products on unsupported configurations and environments.

    In hypervisor, partitioning, cloud instances, and other virtual machine situations, the kernel may trigger an unsupported hardware message or taint based on the hardware data presented to RHEL by the virtual machine (VM).

  • Checks that the system under test (SUT) meets the minimum hardware requirements[1] as follows:

    • RHEL 8: Minimum system RAM should be 1.5GB, per CPU logical core count[2]
    • RHEL 7: Minimum system RAM should be 1GB, per CPU logical core count[3]
  • Checks if the kernel has reported any known hardware vulnerabilities, if those vulnerabilities have mitigations and if those mitigations have resolved the vulnerability. Many mitigations are automatic to ensure that customers do not need to take active steps to resolve vulnerabilities. In some cases this is not possible; where most of these remaining cases require changes to the configuration of the system BIOS/firmware which may not be modifiable by customers in all situations.
  • Confirms the system does not have any offline CPUs.
  • Confirms if Simultaneous Multithreading (SMT) is available, enabled, and active in the system.

Failing any of these tests will result in a WARN from the test suite and should be verified by the partner to have correct and intended behavior.

Success Criteria:

  • The kernel does not have the UNSUPPORTEDHARDWARE taint bit set.
  • The kernel does not report an unsupported hardware system message.
  • The kernel does not report any vulnerabilities with mitigations as vulnerable.
  • The kernel does not report the logic core to installed memory ratio as out of range.
  • The kernel does not report CPUs in an offline state.

5.3.5. Hypervisor/Partitioning

The Hypervisor/Partitioning subtest confirms that the host architecture of the test environment is supported by Red Hat Enterprise Linux (RHEL) 8.

Success Criteria

  • The PASS scenarios of hypervisor/partitioning on Baremetal for RHEL 8 is x86_64, ppc64le, s390x and aarch64.
  • The PASS scenarios of hypervisor/partitioning is x86_64 on, RHEL KVM, VMware, RHEV, QEMU, and HyperV.

5.3.6. Filesystem layout

The Filesystem Layout confirms that the type and minimum size of an image follow the guidelines for each RHEL release. This ensures that the image has a reasonable amount of space required to operate effectively, run applications, and install upgrades for customer use.

Success Criteria:

  • RHEL 8: The root file system for RHEL 8.x is 10GB or greater, and the boot file system is 1GB or greater on an xfs or ext formatted partition.

5.3.7. Installed Red Hat rpms

The Installed Red Hat rpms confirms that RPM packages installed on the system from Red Hat are from the Red Hat Enterprise Linux (RHEL) 8 baseOS and application stream (AppStream) modules, and are not modified.

Non-Red Hat packages may be installed if they are necessary to enable the application, where they are documented, and if they DO NOT modify or conflict with Red Hat packages/software. Red Hat performs a detailed review after the test results are submitted to Red Hat to confirm success or failure when non Red Hat packages are installed.

Success Criteria

  • The installed Red Hat rpm packages are from RHEL 8.
  • The installed Red Hat rpm packages are not modified.
  • The installed non-Red Hat rpm packages are the application or are necessary to enable the application and are documented for joint customers as such.
  • The installed non-Red Hat rpm packages do not conflict with Red Hat provided packages/software available in Red Hat products included in the offering.

5.3.8. Software repositories

Software repositories confirms that relevant Red Hat repositories are configured and GPG keys are imported on the environment under test to avoid potential significant risks from customers being unable to upgrade their Red Hat Enterprise Linux (RHEL) 8 content.

Red Hat provides core software packages/content in Red Hat official software repositories (included with attached subscriptions) which are signed with GPG keys to ensure authenticity of the distributed files. Software provided as part of these repositories is fully supported and reliable for customer production environments.

Non-Red Hat repositories may be configured if they are necessary to enable the application but they must be properly described and approved.

Success Criteria

  • RHEL 8 repositories - BaseOS and AppStream must be enabled
  • GPG keys for RHEL 8 repositories are already imported in the environment
  • The valid repositories are Red Hat Update Infrastructure, Red Hat Satellite, and Red Hat Content Delivery Network
  • Configured non-Red Hat repositories are described and required for the proper operation or installation of the application to be certified
  • Configured non-Red Hat repositories are required for the proper operation of the public cloud when testing is conducted on a Red Hat certified public cloud

Additional resources

5.3.9. Trusted containers

The trusted containers test verifies that any containers installed on the environment under test are known and provided by Red Hat Enterprise Linux (RHEL) 8. It is expected that customers maintain their ability to utilize containers on RHEL 8 in the presence of certified applications. You will be required to clarify the presence of any non RHEL 8 containers.

Success Criteria

  • The RHEL 8 container tool set is installed and operational
  • Any containers present in the environment are supplied as part of a RHEL 8 subscription
  • The default RHEL 8 container registry registry.redhat.io is enabled
Important

This program only certifies non-containerized applications for RHEL 8.

5.3.10. Insights

Red Hat Insights gives customers the ability to predict and prevent problems before they occur through ongoing, in-depth analysis of their infrastructure. It is expected that customers maintainer their ability to utilize Red Hat Insights in the presence of certified applications. The Insights subtest verifies the insights-client rpm is installed and operational.

Success Criteria

  • The insights-client package is installed and operational.

Additional Resources

5.3.11. RPM freshness

RPM freshness confirms that all important and critical security errata released against Red Hat packages are installed. Red Hat encourages partners to update their test environments whenever an errata is released. This test prompts partners to clarify, displays a status (REVIEW) status, and will require detailed review at Red Hat to confirm success or failure if important and critical security errata packages are not installed.

Success Criteria

  • All important and critical security errata released for installed Red Hat packages are current.

Additional resources

5.3.12. SELinux enforcing

Security-Enhanced Linux (SELinux) enforcing subtest confirms that SELinux is enabled and running in enforcing mode on the image. SELinux adds Mandatory Access Control (MAC) to the Linux kernel, and is enabled by default in Red Hat Enterprise Linux (RHEL). SELinux policy is administratively-defined and enforced system-wide. SELinux reduces vulnerability to privilege escalation attacks and limits the damage made during configuration. If a process becomes compromised, the attacker only has access to the normal functions of that process and the files that process has been configured to have access to.

Success Criteria

  • SELinux is configured and running in enforcing mode on the image.

Additional resources

5.3.13. Software modules

Red Hat Enterprise Linux (RHEL) 8 modularity feature is a collection of package available on the system. The software modules test validates modules available on RHEL 8 system.

Success Criteria:

The test fails if there are non-Red Hat software modules.



[2] For more information about hardware support available in RHEL 7 but removed from RHEL 8, see chapter Hardware Enablement in the Considerations in Adopting Red Hat Enterprise Linux 8 document.
[3] For more information about hardware support available in RHEL 6 but removed from RHEL 7, see chapter Changes to Packages, Functionality, and Support in the RHEL 7 Migration Planning Guide document.

5.4. System report (sosreport)

The sosreport test, also known as software/sosreport, captures a basic sosreport.

Red Hat uses a tool called sos to collect the configuration and diagnostic information from a RHEL system, and to assist customers in troubleshooting their system and following recommended practices. The system report subtest ensures that the sos tool functions as expected on the environment under test and captures a basic sosreport.

Success Criteria

  • A basic sosreport can be captured on the environment under test.

Additional resources

Legal Notice

Copyright © 2020 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.