Certification Updates for Red Hat OpenShift 4.11
As with every new release, it is important to stay on top of any changes that may impact how workloads run on this Kubernetes platform. In this specific case, it's worth reviewing recent changes to the default restricted Security Context Constraint (SCC) for new clusters as well as the deprecation of PodSecurityPolicy, both covered in this blog.
Along with the product release, Red Hat OpenShift certification is now available for this new version: software vendors can take advantage of our tools and services to ensure their products meet OpenShift requirements and best practices. Products certified for OpenShift get promoted on our ecosystem catalog and -if managed by an Operator or a Helm chart- via the OpenShift web console. Partners can still certify on older OpenShift versions as long as they are supported (see the life cycle policy for details), but it is always recommended to use the most recent version to be aligned with customers' upgrade cycles.
The OpenShift certification requirements remain the same as with previous releases. But we continuously improve our tools and portal to offer a great experience. This is a good opportunity to highlight some recent enhancements:
- Improvements in the detection of container dependencies in an Operator, and their certification status. Keep in mind that certification must apply to all containers used in your product, and it is a good practice to list all these images in the spec.relatedImages section of your Operator CSV.
- Identify whether a Security Context Constraint (SCC) is needed by an Operator. This information is important for customers as they assess the privileges required for a workload.
- Entries in the ecosystem catalog for products managed by Operators now include the minor versions of OpenShift that are covered. As a reminder, this is controlled by the com.redhat.openshift.versions field in the annotations.yaml file included in the Operator CSV bundle
- Operator bundle validation includes a check for Kubernetes APIs that are deprecated and therefore no longer available in OpenShift. This is currently limited to the Kubernetes version that matches the SDK being used, but we plan to expand it to check against multiple versions.
In addition to the default verification for all workloads, OpenShift certification offers specialized tests ("badges") for products providing network or storage infrastructure to Kubernetes clusters, delivered via CNI or CSI plugins. These specialized options can now be handled through the Partner Connect portal, as part of the project creation for OpenShift certification, to facilitate submitting test results and the corresponding review. Similarly, the workflow to certify cloud-native network functions (CNFs) for the Telco industry can be started using the same portal interface.
Keep in mind that you must provide the information to be used when listing your product in the ecosystem catalog. You can include a product overview, FAQs, installation tips, links to resources, and other information to promote your product's features and capabilities. This task is now highlighted as a mandatory item in the project checklist to ensure it gets completed before the certification is published
To summarize. Take this new release for a test drive, and verify the functionality of your product on it. If any of your certified components (containers, operators, Helm charts) have been updated, run them through our certification process so OpenShift users find the most recent version. Make sure you complete your product listing to be included in catalog.redhat.com, and complete the survey at the end to let us know how we can improve this process.