Ce contenu n'est pas disponible dans la langue sélectionnée.
Chapter 1. Introduction to Red Hat OpenShift certification policies
The Red Hat Openshift certification policy guide covers the technical and operational certification requirements to obtain and maintain Red Hat certification for a software product on Red Hat OpenShift.
To know the test requirements and procedure for achieving this certification, see the Red Hat Software certification workflow guide.
1.1. Audience Copier lienLien copié sur presse-papiers!
Red Hat OpenShift certification is offered to commercial software vendors that deliver cloud-native software products targeting Red Hat OpenShift as the deployment platform.
1.2. Create value for customers Copier lienLien copié sur presse-papiers!
The certification process allows partners to continuously verify if their product meets Red Hat standards of interoperability, security, and life cycle management when deployed on Red Hat OpenShift.
Our customers benefit from a trusted application and infrastructure stack, tested and jointly supported by Red Hat and the Partner.
1.3. Certification and Partner validation Copier lienLien copié sur presse-papiers!
Red Hat offers you the ability to certify or validate your products.
Red Hat-certified products undergo thorough testing and are collaboratively supported with you. These products meet your standards and Red Hat’s criteria, including functionality, interoperability, lifecycle management, security, and support requirements.
Partner-validated products are tested and supported by you. Validation allows you to enable and publish your software offerings more quickly. However, by definition, validated workloads do not include the full thoroughness of Red Hat certification. We encourage you to continue efforts toward stabilization, upstream acceptance, Red Hat enablement, and Red Hat certification.
The validation option is not available for all infrastructure software.
Understanding the differences between certification and validation, along with the capabilities, limitations, and achievements of your products, is essential for you and your customers.
1.4. Support responsibilities Copier lienLien copié sur presse-papiers!
Red Hat customers receive the best support experience when using components from our robust ecosystem of certified enterprise hardware, software, and cloud partners.
Red Hat provides support for Red Hat-certified products and Red Hat software according to the Red Hat Service Level Agreement (SLA). If a certified or validated third-party component is involved in a customer issue, Red Hat collaborates with you to resolve it according to the Third party support policy.
Red Hat does not stipulate customer support policies. However, we require your support in assisting customers with diagnosing and resolving issues related to the functionality, interoperability, lifecycle management, and security of your software in conjunction with ours.
Being listed as certified or validated in the Red Hat Ecosystem Catalog indicates your commitment to supporting your products and providing reliable solutions for our joint customers, adhering to your policies with Red Hat products.
1.5. Targeted products for certification and validation Copier lienLien copié sur presse-papiers!
Certification and validation is available for workload products that target Red Hat OpenShift as their deployment platform. Red Hat recommends that you manage the product’s life cycle by using technology native to Kubernetes, such as Operators or Helm charts, because they deliver a user experience that is closely integrated with Red Hat OpenShift. For these two options, certification covers the packaging format and compatibility with the Red Hat OpenShift tools. If your product uses a different technology for installation and upgrades, certification will be limited to the container images.
Products that deliver infrastructure services for Red Hat OpenShift, storage services provided through a CSI driver or networking services integrated via a CNI plugin, require tight integration with the platform’s life cycle management. Therefore, they do not qualify for validation and must be managed by an Operator and demonstrate compliance with the corresponding Kubernetes APIs.
Specialized certification and validation is available for cloud-native network functions for the Telecommunications market.
1.6. Prerequisites and process overview Copier lienLien copié sur presse-papiers!
1.6.1. Prerequisites Copier lienLien copié sur presse-papiers!
- Join the Red Hat Partner Connect program.
- Accept the standard Partner Agreements along with the terms and conditions specific to containerized software.
- Enter basic information about your company and the products you wish to certify through the Red Hat Partner Connect portal.
- Test your product to verify that it behaves as intended on OpenShift.
- Support OpenShift as a platform for the product being certified or validated, and establish a support relationship with Red Hat. You can do this through the multi-vendor support network of TSANet, or through a custom support agreement.
1.6.2. Process overview Copier lienLien copié sur presse-papiers!
The Red Hat certification and partner validation procedures are outlined below. See the Red Hat Software Certification Workflow Guide for details on how to complete each step listed below.
1.6.2.1. Certification procedure Copier lienLien copié sur presse-papiers!
- Complete the prerequisites
- Create your product
- Create and associate components for each product component
- Complete the product listing checklist
Complete the certification requirements for each component as appropriate
Conduct functional certification (if appropriate)
- Complete the component certification checklist for each component
- Publish your components
- Publish your product
1.6.2.2. Validation procedure Copier lienLien copié sur presse-papiers!
- Complete the prerequisites
- Create your product
- Complete your Product List details
- Create a Validation request
- Complete the product listing checklist
- Complete the validation checklist
- Fill in the questionnaire
- Wait for Red Hat to review and approve the questionnaire
- Publish your product
1.7. Supported Red Hat OpenShift versions Copier lienLien copié sur presse-papiers!
Red Hat OpenShift software certification and validation is available for releases of Red Hat OpenShift v4.x which are in the Full, Maintenance or Extended Update Support (EUS) life cycle phases.
1.8. Supported architectures Copier lienLien copié sur presse-papiers!
Certification is available for all supported architectures for Red Hat OpenShift Container Platform v4.x releases. At present this includes x86_64, s390x, ppc64, and aarch64.
Certifications are awarded to a single architecture. Apply for multiple certifications if your product supports more than one architecture.
1.9. Lifecycle Copier lienLien copié sur presse-papiers!
Red Hat certifications and validations remain valid for 12 months or until the corresponding Red Hat OpenShift Container Platform (RHOCP) v.4.x release exits the Extended Update Support Term 2 of the RHOCP lifecycle, whichever time period is shorter. To maintain the certification or partner validation status, you must recertify or revalidate on newer versions of your software or Red Hat OpenStack Platform (RHOSP). Certifications, validations and associated products remain published until they are no longer valid or the Red Hat product version is retired from the catalog.
OpenShift now includes Extended Update Support (EUS) and Extended Update Support Term 2 (EUS-T2) options, which require changes to product build and release practices, as well as ISV certification.
The window for certifications or validations opens with the GA release of the minor version through the OpenShift Extended Update Support based on the even and odd schedules.
- Even-numbered minor releases: The window will close at the end of either Extended Update Support or Extended Update Support Term 2, whichever is later.
- Odd-numbered minor releases: The window will close simultaneously with the preceding even-numbered release (e.g., 4.15 will close with 4.14 at the end of Extended Update Support Term 2). This is because even-numbered releases have a longer support lifecycle. Although an odd-numbered release reaches its end-of-life sooner, it becomes relevant during updates between even-numbered releases in the extended update support phase, serving as intermediate steps. Certifying software for these end-of-life releases ensures that critical bug fixes and security updates are available, preventing regressions during customer updates.
ISV certification tools and product build or release engineering will support odd-numbered minor releases for longer than indicated on the lifecycle page.
Supporting EUS-to-EUS updates is crucial for a seamless customer experience. For example, if you certify an ISV software version 1 on RHOCP 4.14 and version 3 is on RHOCP 4.16, dual certification on 4.14 can be beneficial. This is particularly relevant if the software supports direct upgrades from version 1 to version 3 and version 3 is compatible with RHOCP 4.14. In such cases, certifying version 3 on RHOCP 4.14 allows customers to upgrade their software while remaining on RHOCP 4.14 before transitioning to 4.16, ensuring a smoother process and minimizing disruptions.
Refer to the Red Hat OpenShift Container Platform Life Cycle Policy for more details.
Red Hat encourages you to plan even-to-even updates for OpenShift releases reaching "Maintenance Support Ends". However, this extended product support offers flexibility for any necessary update paths, such as progressing from OpenShift 4.14 through 4.15 to 4.16, ensuring uninterrupted support for our joint customers.
1.9.1. Recertification Copier lienLien copié sur presse-papiers!
Red Hat OpenShift Container Platform innovates at a rapid pace, as is reflected in the Red Hat OpenShift Container Platform Lifecycle Policy. It is important to approach OpenShift and certification testing as a continuous process to ensure ongoing interoperability and support for customers.
You must recertify your products in the following scenarios:
- Certifying another version of your product
- Making another version of your product available through a Red Hat in-product software catalog (index/registry/repo/etc.)
- Supporting another version or architecture of Red Hat OpenShift Container Platform (RHOCP)
- Making a material change to your product’s build, installation, upgrade process, or adding new functionality
- Your product contains a critical Common Vulnerability and Exposure (CVE) that is older than 3 months
- Your product contains an important CVE that is older than 12 months
- Your product was certified more than 12 months ago
A material change is any change that alters the outcome of certification testing, impacts a customer’s experience of your product on OpenShift, impacts a customer’s experience of OpenShift, or impacts a customer’s ability to utilize any part of their Red Hat subscription(s).
Red Hat provides multiple mechanisms to monitor certified containers for critical vulnerabilities (CVEs). This allows you to continuously monitor and identify for critical vulnerabilities. These mechanisms will help you determine when to rebuild and recertify.
1.9.2. Additional validations Copier lienLien copié sur presse-papiers!
Red Hat OpenShift Container Platform innovates at a rapid pace, as is reflected in the Red Hat OpenShift Container Platform Lifecycle Policy. It is important to approach OpenShift and certification testing as a continuous process to ensure ongoing interoperability and support for customers.
You require additional validations for your products in the following scenarios:
- Validating another version of your product
- Supporting another version or architecture of Red Hat OpenShift Container Platform
- Making a material change to your product
- Your product was validated more than 12 months ago
A material change is any change that alters the outcome of certification testing, impacts a customer’s experience of your product on OpenShift, impacts a customer’s experience of OpenShift, or impacts a customer’s ability to utilize any part of their Red Hat subscription(s).
1.10. Product naming and branding Copier lienLien copié sur presse-papiers!
Select unique product names and branding that comply with Red Hat trademark guidelines. This helps our joint customers clearly identify products that use Red Hat Marks and their source. This policy covers all catalog listings and individual product components.
1.11. Software dependencies Copier lienLien copié sur presse-papiers!
A key benefit of Red Hat Certification is support. Ensure to check if you in coordination with Red Hat, support all the software necessary for customers to deploy and utilize your software on RHOCP.
1.12. Functional verification Copier lienLien copié sur presse-papiers!
You must ensure that your product, with the same packages and components that you submitted for certification, works with the configurations supported by RHOCP.
Ensure your product does not make any modifications to the RHOCP stack, including the host operating system, other than configuration changes that are covered in the product documentation. Unauthorized changes can impact the support from Red Hat.
Red Hat encourages you to check that your product is capable of running on any node in a OpenShift cluster, regardless of the type of Red Hat OpenShift deployment (bare metal, virtual environment, or cloud service), installation process (IPI or UPI), or cluster size. If there are any limitations due to dependencies on hardware components, public cloud services, or any other cluster configuration requirements, these should be mentioned in the product’s documentation which should be linked to your product catalog listing.
1.13. Security contexts Copier lienLien copié sur presse-papiers!
To reduce security risks, ensure that your products run in the most restrictive Security Context Constraint (SCC). For example, restricted-v2 for Red Hat OpenShift 4.12. If the product requires additional privileges, Red Hat recommends using the most restrictive SCC that provides the right capabilities. This configuration information should be included as part of the product documentation, and the certification tests must be conducted using the same security settings that are recommended for end users.
1.14. Publishing Copier lienLien copié sur presse-papiers!
1.14.1. Red Hat Ecosystem Catalog Copier lienLien copié sur presse-papiers!
When you complete the Red Hat Enterprise Linux (RHEL) Certification or the partner validation workflow, Red Hat publishes an entry in the Red Hat Ecosystem Catalog. This includes a product entry and relevant information collected during the process.
Products with certifications include the associated component data for containers, Helm charts and operators. Products without any certifications do not include component information.
1.14.2. Red Hat in-product catalogs Copier lienLien copié sur presse-papiers!
Red Hat products include in-product catalogs for direct use by customers. The in-product catalogs allow customers to install, run, and manage Red Hat certified software from the appropriate interface within the Red Hat product. For example, the ISV container registry, the chart repository and operator index.
Additionally, products managed by Operators or Helm charts are also included in the corresponding Red Hat Certified Operator Index or the OpenShift Helm Charts Repository, to facilitate installation and upgrades by default. Both are presented to Red Hat OpenShift users through the OpenShift console.
You may opt out of being published in the Red Hat Certified Operator Index or Helm Charts Repository if it is not compatible with your software distribution model. You are responsible for testing the alternate distribution and update processes, which must be included in your product documentation.
Similarly, you may opt out of being published in the Red Hat in-product catalogs if it is not compatible with your software distribution model. You are responsible for testing the alternate distribution and update processes, which must be included in your product documentation.