[vc_row][vc_column][multi_title_header_module blueheader=”Certified Provider” blackheader=” Requirements”]
[/multi_title_header_module][/vc_column][/vc_row][vc_row][vc_column][middle_content_module]
Overview
The Cloud Foundry PaaS Certification program of CloudFoundry.org Foundation (the “Foundation”) is designed to certify products and services (“offerings”), that ship include and/or use the Foundation’s Cloud Foundry Application Runtime (CFAR) software, include that software in an unmodified form as shipped by the Foundation’s project teams.
The certification program also aims at increasing CFAR adoption in the industry, by ensuring certified offerings are of good quality, and suitable for production use.
Certified products and services are expected to differentiate themselves, but only via (1) non-functional attributes (availability, customer support, etc…) and (2) functional differences based on explicitly defined plugin points within the CFAR platform architecture. Functional differences include features and functions built on top of the CFAR platform (e.g.: CF as part of a larger offering or suite of offerings).
Applicable Offerings
The certification program is designed to work across a spectrum of offering types, including (but not limited to): software distributions, distribution as part of a hardware stack, managed private PaaS / Cloud services and online PaaS services.
The certification requirements apply equally to all of these offering types, with some requirement clarification provided based on offering type.
Requirements for Certification
General Requirements
Certified offerings are required to use the exact software packaged in specific releases of both the Cloud Foundry Application Runtime and Developer CLI tool. Details for each component are noted below.
When certifying and during a verification audit, the program participant must provide the Foundation the exact release numbers for each required component.
“Use” is defined as the platform components performing the functions they are designed to perform within the architecture of the CFAR platform by the Foundation project teams. Shipping a component, but not using it for it’s intended purpose, does not meet the requirement. Similarly, shipping a component side-by side with an alternative implementation is only acceptable if the required component is the default option for users.
No feature differentiation may be added by modifying the code of the required components.
Exceptions:
- Exceptions to the “exact software” requirement are only allowed for bug fixes or vulnerability patches, which do not add or change any features, with the requirement that the change is sent upstream to the relevant Foundation project(s). Specific to vulnerability patches, organizations with a certified offering are required to follow the Foundation’s vulnerability reporting process for any vulnerability identified as documented here: https://cloudfoundry.org/security/
- During initial certification and / or during any inspection of an offering’s technical compliance, the program participant must provide a listing of all exceptions, with relevant audit trails of the fix being sent to the Foundation project(s).
Current versions of certified products and services are expected to contain versions of the required components in the form released by Foundation project teams, no older than 6 months (unless the component has not had a release in that time), measured at the time of certification.
- For online PaaS, this applies to the currently running environment. Particularly, this applies to any new customer or new application deployment within the platform.
- For offerings that are “shipped” or dedicated to a single customer, this applies specifically to what a new customer or a customer being upgraded will receive from the program participant.
In the case of any uncertainty regarding these requirements, program participant should ask for the clarification by the Foundation via [email protected]. The Foundation reserves the right to determine how these requirements are interpreted in cases where clarification is required.
Application Runtime
The Application Runtime portion of a certified offering must include the following components:
- Cloud Controller: https://github.com/cloudfoundry/capi-release
- Router: https://github.com/cloudfoundry-incubator/routing-release
- Diego: https://github.com/cloudfoundry/diego-release
- Garden: https://github.com/cloudfoundry-incubator/garden-runc-release and / or https://github.com/cloudfoundry-incubator/garden-windows-bosh-release
- Cflinuxfs2: https://github.com/cloudfoundry/cflinuxfs2-release
- UAA: https://github.com/cloudfoundry/uaa-release
- Logging & Metrics: https://github.com/cloudfoundry/loggregator-release
The components of the Cloud Foundry Application Runtime should be versions of the associated projects tested together by the Foundation’s Release Integration project team, although this is not required and component compatibility likely exists in more combinations than what is being tested by the Release Integration project team’s pipeline.
For the purpose of clarity, the use of Cloud Foundry BOSH is not required as the method of deploying or managing the Cloud Foundry Application Runtime. Use of “BOSH Release” repositories when identifying required components is for convenience in identifying the collection of source code repositories that together form each component.
Developer CLI
Certified offerings must provide users with the official “cf” Command Line Interface (CLI) tool as the primary CLI for interacting with the Cloud Foundry Application Runtime platform. The CLI provided to users must be an unmodified version of the tool released by the Foundation’s CLI project team. This may be a redistribution of the released bits, or a pointer to an official download or distribution channel of the CLI project’s releases.
Updates to Requirements
The Foundation may update these requirements in accordance with its by-laws. Future updates may include processes for initial certification, audit, or re-certification.
Generally, the Foundation will aim to undergo a review of these requirements at least annually, with the review beginning mid-year in order to give certified offerings time to meet any new requirements prior to the next certification year starting.
[/middle_content_module][/vc_column][/vc_row]