Red Hat SummitRed Hat OpenShift Software Certification Policy Guide
For Use with Red Hat OpenShift
Abstract
Making open source more inclusive
Red Hat is committed to replacing problematic language in our code and documentation. We are beginning with these four terms: master, slave, blacklist, and whitelist. Due to the enormity of this endeavor, these changes will be gradually implemented over upcoming releases. For more details on making our language more inclusive, see our CTO Chris Wright’s message.
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
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
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
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
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
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
1.6.1. Prerequisites
- 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
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
- 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
- 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
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
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
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
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
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
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
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
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
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
1.14.1. Red Hat Ecosystem Catalog
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
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.
Chapter 2. Requirements for container images
Certified container images must comply with the following requirements to ensure that:
- The operating system libraries are covered as part of the end-user Red Hat OpenShift support subscription.
- The image is scanned to avoid introducing known security vulnerabilities in customer environments.
2.1. Image content requirements
| Requirement | Justification |
|---|---|
| Container images must declare a non-root user unless their functionality requires privileged access. To certify container images requiring root access, you must:
Test name: RunAsNonRoot | Ensures that containers do not run as the root user unless required. Images running as the root user can pose a security risk. |
| Container images must use a Universal Base Image (UBI) provided by Red Hat. You can add additional RHEL packages to the UBI images, except for kernel packages. Test name: BasedOnUbi | Ensures that application runtime dependencies, such as operating system components and libraries, are covered under the customer’s subscription. |
| Container images must not change content provided by Red Hat packages or layers except for files that both you or the customers can change, such as configuration files. Test name: HasModifiedFiles | Ensures that Red Hat does not deny support on the basis of unauthorized changes to Red Hat components. |
|
Container images must have a Test name: HasLicense | Ensures that customers are aware of the terms and conditions applicable to the software included in the image. |
| Uncompressed container images must have less than 40 layers. Test name: LayerCountAcceptable | Ensures that images run appropriately on containers. Too many layers could degrade the performance. |
| Container images must not include RHEL kernel packages. Test name: HasNoProhibitedPackages | Ensures compliance with RHEL redistribution rules for partners. |
| Container images must not contain Red hat components with identified important or critical vulnerabilities. Test name: N/A. The Red Hat Certification Service conducts this scan. | Ensures that customers are not exposed to known vulnerabilities. |
| Container image names must not begin with any Red Hat Marks. Test name: HasProhibitedContainerName | Ensures compliance with Red Hat trademark guidelines. |
2.2. Image metadata requirements
| Requirement | Justification |
|---|---|
| Container images must include the following labels:
Test name: HasRequiredLabel |
Ensures that customers can obtain information about the image provider and the content of the images in a consistent way. |
| Container image label content must not begin with any Red Hat Marks:
Test name: HasNoProhibitedLabels | The image name must follow the Red Hat trademark guidelines. |
| Container images must include a unique tag that is descriptive of the certified image. Red Hat recommends appending the image version and its build date or released date to the unique tag. Floating tags, such as latest although not adequate for certification, can be added to the image in addition to the descriptive tag. Test name: HasUniqueTag | Ensures that images can be uniquely identified. |
2.3. Image maintenance requirements
Partners are responsible for monitoring the health status of their certified containers. When an image rebuild is required because of new functionality or a security update, submit the updated container image for recertification and publication.
Partners must keep the application components up-to-date and rebuild their container images periodically.
Chapter 3. Products managed by an Operator
Operators must be capable of deploying your software product on Red Hat OpenShift, using Operator Lifecycle Manager (OLM) from the targeted Red Hat OpenShift releases.
If any specific hardware requirements are essential to run your certified operator, Red Hat recommends informing your customers by listing all the requirements on your product’s system requirement page and linking it to your product page on the Red Hat Ecosystem catalog.
3.1. Operator requirements
The version range can include a future release version of Red Hat OpenShift Container Platform (RHOCP). Therefore, only Operators that do not need recertification will be listed as certified for and included in the Red Hat Certified Operator Index for the later RHOCP version when it becomes generally available.
| Requirement | Justification |
|---|---|
| The Operator bundle must successfully pass the Operator SDK bundle validation. Red Hat recommends the usage of the SDK to create the Operator, to ensure that the format is correct. | To ensure correct format and compatibility with Operator Lifecycle Manager (OLM). |
| The Operator must update the status field of each custom resource (CR). | To ensure that users can determine the running state of the CR and identify potential failures. |
|
The cluster service version (CSV) in the Operator bundle must include all the fields indicated in Required CSV fields as well as the following required fields under
Other optional annotations can be defined as well, such as for the following Kubernetes plugins:
For more information about required annotations, optional annotations, and example usage in CSVs, see Operator metadata annotations. | Provides detailed information about the product managed by this Operator to users and support organizations. |
|
The Operator bundle must indicate the minor versions of OpenShift that the target product supports by setting the Annotation syntax: a) Restrict to a single RHOCP version: "=v4.17" b) Restrict to a version range: "v4.16-v4.17" c) Open-ended version range: "v4.16" If the open-ended version range listed is deprecated, the operator bundle will only appear in the fully supported and maintained versions. The version range must include one or more current RHOCP versions, that are in the Full Suport, Maintenance Support, EUS, or EUS Term 2 life cycle phases. The range may directly or implicitly include one or more future versions of RHOCP. Upon the release of a new RHOCP minor version, Operators with ranges that include the new minor version and are in good standing regarding the lifecycle and recertification policies, will automatically be certified and published for the new minor version of RHOCP. | Red Hat expects and requires that you test and verify your product with new minor releases of Red Hat OpenShift as they become available. |
| The Operator must not use any APIs that are not present in all versions of Red Hat OpenShift included in this range. | Ensures that any APIs used are available in the targeted versions. |
| The CSV in the Operator bundle must indicate all the CRDs Owned by the Operator. | To ensure adequate tracking and management of CRD lifecycle. |
|
The CSV in the Operator bundle must indicate all the container images needed to perform its function, using the | To correctly identify all the dependencies. |
| The Operator name must be different from any other Operator name already published in the Community, Certified, and Red Hat catalogs. The Operator name must not begin with a Red Hat Mark. | To avoid name conflicts, customer confusion and to follow Red Hat trademark guidelines. |
3.2. Operand requirements
Each container managed by the Operator (Operands) must be certified by Red Hat and must fulfill the requirements listed in the Requirements for container images section.
Chapter 4. Products managed by Helm charts
The Helm chart must be capable of deploying your product on Red Hat OpenShift, using the Helm utilities provided by this platform. For more information about using Helm charts on Red Hat OpenShift, see Working with Helm charts.
To be certified, the Helm chart must meet the following requirements.
| Requirement | Justification |
|---|---|
| All containers used by the Helm chart must be Red Hat certified containers. | Operating system libraries in the certified container images are covered by the Red Hat OpenShift support, and continuously monitored for security vulnerabilities. For more information on container certification requirements, see Requirements for container images. For more information about the steps to certify your containers, see Working with containers. |
| The chart’s apiVersion field must be v2.0. | Chart must be compatible with Helm 3 (for example, apiVersion v2), the Helm version supported in OpenShift. |
| Chart must contain a README.md file. | Provide basic information about the chart in a human-readable format. |
| Chart must set the kubeVersion field to indicate the minimum Kubernetes version supported. | To determine chart compatibility with specific versions of OpenShift. For information on Kubernetes versions used in OpenShift, see What version of the Kubernetes API is included with each OpenShift 4.x release? article. |
| Chart must include one or more tests located in the templates directory. | To verify successful chart installation. |
|
Chart must include a | Identify chart inputs and provide proper validation. |
| Chart must not contain any Custom Resource Definitions (CRDs). | Lifecycle of Custom Resource Definitions (CRDs) needs to be managed properly. Red Hat recommends an Operator for performing this task. For more information about Operators, see Working with Operators. |
| Chart must pass the helm lint command. | Ensuring correct chart format. |
|
Chart must include the | Provide a name that can be used when displaying the chart on the OpenShift console. This name must follow Red Hat trademark guidelines and policies. |
Chapter 5. Functional certification for OpenShift badges
Certification badges extend the Red Hat OpenShift certification into specific functional areas or infrastructure services. A badge indicates that a certified product delivers capabilities that have been verified by Red Hat, such as conformance with Kubernetes Container Storage Interface (CSI) or Container Networking Interface (CNI) APIs.
If your product delivers any of the capabilities described in this section, Red Hat encourages you to conduct additional tests. This helps you to identify your product accordingly on the Red Hat Ecosystem Catalog.
5.1. Container Network Interface (CNI)
The CNI badge is a specialization within Red Hat OpenShift certification. It is available for networking products that integrate with OpenShift using a CNI plug-in.
5.1.1. Plug-in requirements
The plug-in must conform to the CNI specification version 0.3.1 or later.
You must manage the CNI plug-in through an Operator that meets the Operator certification requirements described in this document. To manage the updates to the CNI plug-in, the Operator must have the Seamless Upgrades capability and reflects this in the CSV.
5.1.2. OpenShift interoperability requirements
In addition to the default requirements for functional verification, the OpenShift cluster that you use to verify the CNI functionality must have the Multus CNI plug-in enabled during all tests. All the components that are installed on the host must be tested and supported on the versions of Red Hat Enterprise Linux and Red Hat Enterprise Linux CoreOS.
The CNI plug-in must support OpenShift Virtualization. Any unsupported or degraded features of the plug-in or OpenShift Virtualization when used in combination, must be indicated in your product documentation.
As part of the CNI certification badge, the CNI plugin can be verified for compatibility with Red Hat OpenShift Service Mesh.
5.1.3. CNI lifecycle management requirements
The plug-in must ensure minimal impact on upgrades for either major or minor plug-in releases. The plug-in upgrades should not require a full node reboot (whether major or minor) and must preserve existing connections during cluster upgrades.
The plug-in must allow new connections during upgrades. If new or existing connection preservation is not possible, this must be documented along with detailed upgrade steps, for example, if a full cluster drain or node cordoning/drain is required.
The plug-in documentation must show any difference in upgrade procedure between minor releases, bug fixes, or major updates.
Certifications are specific to the OpenShift minor release tested. Partners are required to recertify their product on new minor OpenShift releases.
5.1.4. CNI test compliance
The plug-in must pass the network tests of the OpenShift End-to-End Tests, based on the Kubernetes End-to-End Tests.These tests exercise the basic functions of the plug-in and show conformance to Kubernetes networking expectations.
It is mandatory to complete the corresponding virtualization tests to validate the interoperability between the CNI plug-in and Red Hat OpenShift Virtualization.
If you want to check the interoperability between the CNI plug-in and Red Hat OpenShift Service Mesh, complete the corresponding service mesh tests as part of the certification. Running the service mesh tests is optional.
5.2. Container storage interface (CSI)
The CSI badge is a specialization within Red Hat OpenShift Certification. It is available to the storage products that integrate with OpenShift using a CSI driver.
5.2.1. Driver requirements
The CSI driver must implement version 1.0 or later of the CSI specification. The CSI driver must implement the Create and Delete volume capabilities. All other capabilities are optional but, if implemented and supported, they must be declared via a manifest file see (example manifest file) so they can be tested.
5.2.2. Operator and sidecar requirements
The CSI driver must be deployed and managed through an Operator that meets the Operator certification requirements described in this document. The requirements to use certified operands (containers) also apply to the driver’s sidecar images. You should build and maintain their sidecar images so they can meet this criterion. You can select a sidecar image published and maintained by Red Hat, available as a part of OpenShift. If you do so, verify the interoperability of your CSI driver with the sidecars, as well as test and incorporate sidecar updates when available.
5.2.3. OpenShift interoperability requirements
All components installed on the host must be tested and supported on the versions of Red Hat Enterprise Linux and Red Hat CoreOS, used by the OpenShift release targeted for certification.
The CSI driver should support the storage features listed in the OpenShift Virtualization storage feature matrix, so users can take full advantage of platform services for virtual machines. The CSI product documentation must indicate if any of these features are not supported by the driver.
5.2.4. CSI lifecycle management requirements
During upgrades, the Container Storage Interface (CSI) driver must manage volumes without data loss, continue to handle requests idempotently, maintain correct placement, and report status to ensure reliable storage.
The driver must ensure minimal impact on upgrades for either major or minor releases. The driver upgrades should not require a full node reboot, whether major or minor, and must preserve existing volume mounts during cluster upgrades.
The driver must allow volume operations during upgrades. If new volume operations or existing volume mount preservation is not possible, you must document this along with detailed upgrade steps, for example, if a full cluster drain or node cordoning/drain is required.
The driver documentation must show any difference in upgrade procedure between minor releases, bug fixes, or major updates.
Certifications are specific to the OpenShift minor release tested. Partners are required to recertify their product on new minor OpenShift releases.
5.2.5. CSI test compliance
The plugin must complete the CSI tests of the OpenShift End-to-End Tests, based on the Kubernetes End-to-End Tests.
Execute the tests for each of the storage protocols supported (such as iSCSI, NFS, FC) and must match the declared capabilities.
Chapter 6. Partner documentation requirements
The product documentation that partners provide to their customers must:
- Include instructions on how to install and update your product on OpenShift using the certified Operator or Helm chart as applicable.
- List OpenShift as a supported platform.
Add links to your product documentation in the Product Listing information, provided as a part of the certification process.
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}