angellk
commented
2 weeks ago @jbw976 In preparation for Crossplane to be picked up by a TOC member after the KubeCon freeze period -- and prior to TOC member assignment -- please:
- review the definition of an adopter
- verify 5-7 project adopters that can and are willing to be interviewed by the TOC reviewer(s) and
- submit information for each adopter to the Adopter Interview Questionnaire form.
- complete the Security Self Assessment as required by the Graduation application
jbw976
Crossplane Graduation Application
v1.5 This template provides the project with a framework to inform the TOC of their conformance to the Graduation Level Criteria.
This graduation application issue is a continuation of the Crossplane graduation proposal started using the previous format in https://github.com/cncf/toc/pull/1254 on Feb 5, 2024.
Project Repo(s): https://github.com/crossplane/crossplane is the core Crossplane project
Project Site: https://www.crossplane.io/
Sub-Projects: Crossplane does not have a formal sub-project designation, but there are additional projects/repositories under the https://github.com/crossplane/ organization, and community led extensions in the https://github.com/crossplane-contrib organization. All projects under these organizations fall under the Crossplane governance.
Communication: https://slack.crossplane.io/
Project points of contacts:
Graduation Criteria Summary for Crossplane
Adoption Assertion
The project has been adopted by the following organizations in a testing and integration or production capacity:
Adopters of the Crossplane project that have chosen to share their adoption story publicly can be found in the ADOPTERS.md file in the main Crossplane repository. Currently, there are over 60 public adopters of the project, and there are more that are willing to share their story with the TOC privately. Some notable Crossplane public adopters include Nike, Autodesk, Grafana, NASA Science Cloud, Elastic, Akamai, SAP, IBM, VMWare Tanzu, and Nokia.
Criteria
Application Process Principles
Suggested
N/A
Required
Jared Watts (@jbw976) presented Crossplane's graduation proposal and project update to TAG App Delivery on Feb 7, 2024, as noted by @angellk in https://github.com/cncf/toc/pull/1254#issuecomment-1978304903.
Notes from TAG App Delivery can be found linked from the TAG statement of Crossplane's graduation presentation in https://github.com/cncf/toc/pull/1254#issuecomment-1978304903, and a formal review/recommendation from the TAG will be provided soon.
A complete due diligence document was prepared by the project team when applying for Incubation and reviewed by TAG App Delivery to provide their feedback and recommendations. This document has now been updated in preparation for Graduation to include notable project progress and accomplishments since Incubation and how the specific concerns raised by the TAG have been addressed.
Crossplane operates according to well defined vendor-neutral governance in https://github.com/crossplane/crossplane/blob/master/GOVERNANCE.md, and all project communication, messaging, and collaboration is vendor-neutral.
The official project charter states that the project is vendor-neutral as well: https://github.com/crossplane/crossplane/blob/master/CHARTER.md#what-crossplane-is
The Crossplane project has reviewed and understands the expectations as it has continued to move forward through the maturity levels as described in the process README and graduation criteria.
Crossplane has demonstrated this understanding through all applications/proposals for each maturity level:
Completion of this due diligence document, resolution of concerns raised, and presented for public comment satisfies the Due Diligence Review criteria.
Complete end user project documentation can be found in https://docs.crossplane.io/. Contributor documentation for the Crossplane project can be found in https://github.com/crossplane/crossplane/tree/master/contributing, and documentation specific contributing guide can be found in https://docs.crossplane.io/contribute/.
Governance and Maintainers
Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy.
Suggested
The project governance has undergone a few revisions in its history since the project's creation. These commits/updates can be found in the git history at https://github.com/crossplane/crossplane/commits/master/GOVERNANCE.md. We started the project and early on had fairly detailed governance, because we are also the creators of the Rook project and had experience developing a well defined project governance there first.
Required
The Crossplane project has had well defined governance in place since entry into the CNCF Sandbox, which can be found in the main repo’s GOVERNANCE.md file. All aspects of the life cycle for Crossplane leadership positions, including the steering committee and repository maintainers (committers) are described in detail within this governance document. The steering committee members, currently from Upbound, Apple, and Nokia, can be found in the project governance also. Repository maintainers can be found in the OWNERS.md file of each separate Crossplane repository that make up the project.
The governance is up to date with the latest iteration of the steering committee membership, which occurred early in 2024. All processes for maintainers, conflict resolution, etc. are defined and up to date in this governance document.
All meetings within the Crossplane community and ecosystem are tracked in the community calendar. This calendar as well as other ways to get involved are highlighted prominently in the project's main README.
The governance has a "maximum representation" section that outlines how vendor neutrality is enforced over the lifetime of the project and leadership elections: https://github.com/crossplane/crossplane/blob/master/GOVERNANCE.md#maximum-representation
The project charter also reinforces the notion of vendor-neutrality: https://github.com/crossplane/crossplane/blob/master/CHARTER.md#what-crossplane-is
Changes to governance has a clearly defined process in https://github.com/crossplane/crossplane/blob/master/GOVERNANCE.md#updating-the-governance.
Project leadership (steering committee) election process is defined in https://github.com/crossplane/crossplane/blob/master/GOVERNANCE.md#election-process.
Process for how each individual repository under the crossplane organization(s) are maintained can be found in https://github.com/crossplane/crossplane/blob/master/GOVERNANCE.md#repository-governance.
Contribution acceptance is augmented by the contributing guide with https://github.com/crossplane/crossplane/tree/master/contributing#contributing-code and https://github.com/crossplane/crossplane/tree/master/contributing#code-review-process.
[x] Document how role, function-based members, or sub-teams are assigned, onboarded, and removed for specific teams (example: Security Response Committee).
Repository maintainers are added by: https://github.com/crossplane/crossplane/blob/master/GOVERNANCE.md#becoming-a-maintainer
Repository maintainers are removed by: https://github.com/crossplane/crossplane/blob/master/GOVERNANCE.md#removing-a-maintainer
Steering committee members are elected by: https://github.com/crossplane/crossplane/blob/master/GOVERNANCE.md#election-process
[x] Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.
The steering committee membership and details can be found in https://github.com/crossplane/crossplane/blob/master/GOVERNANCE.md#initial-steering-committee, and contact info for the committee as a whole is provided.
The maintainers of each repository in the crossplane and crossplane-contrib organizations are listed in the OWNERS.md file in each individual repository. For example:
core Crossplane: https://github.com/crossplane/crossplane/blob/master/OWNERS.md
crossplane-runtime: https://github.com/crossplane/crossplane-runtime/blob/master/OWNERS.md
provider-ansible: https://github.com/crossplane-contrib/provider-ansible/blob/main/OWNERS.md
provider-palette: https://github.com/crossplane-contrib/provider-palette/blob/main/OWNERS.md
[x] A number of active maintainers which is appropriate to the size and scope of the project.
Across the entire Crossplane project, there are 148 different companies that have committers (individuals with write permissions) on at least one repository.
[x] Document a complete maintainer lifecycle process (including roles, onboarding, offboarding, and emeritus status).
Repository maintainers are added by: https://github.com/crossplane/crossplane/blob/master/GOVERNANCE.md#becoming-a-maintainer
Repository maintainers are removed by: https://github.com/crossplane/crossplane/blob/master/GOVERNANCE.md#removing-a-maintainer
[x] Demonstrate usage of the maintainer lifecycle with outcomes, either through the addition or replacement of maintainers as project events have required.
Using the same example repository maintainers (OWNERS.md) from a previous question, we can see the history of these files as maintainer membership changes over time, with both additions and removals (or movement to emeritus status):
https://github.com/crossplane/crossplane/commits/master/OWNERS.md
https://github.com/crossplane/crossplane-runtime/commits/master/OWNERS.md
https://github.com/crossplane-contrib/provider-palette/commits/main/OWNERS.md
https://github.com/crossplane-contrib/provider-ansible/commits/main/OWNERS.md
[x] Project maintainers from at least 2 organizations that demonstrates survivability.
Across the entire Crossplane project, there are 148 different companies that have committers (individuals with write permissions) on at least one repository, which is a great demonstration of organizational diversity.
Also, the steering committee for the Crossplane project is composed of individuals from 3 separate organizations: Apple, Nokia, and Upbound.
Yes,
OWNERS.mdfiles in each Crossplane project repository should reflect the documented maintainer roles defined in the governance. For example, https://github.com/crossplane/crossplane/blob/master/OWNERS.md.Crossplane project and community adhere to the CNCF Code of Conduct, e.g., https://github.com/crossplane/crossplane/blob/master/CODE_OF_CONDUCT.md.
The CNCF Code of Conduct is linked from the root of the core Crossplane repository: https://github.com/crossplane/crossplane/blob/master/CODE_OF_CONDUCT.md
Crossplane does not have formally defined "subprojects", but all repositories under the crossplane and crossplane-contrib repository adhere to the well defined governance.
N/A
Contributors and Community
Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy.
Suggested
Contributor roles fall into 3 tiers: member, maintainer, and steering committee. The roles and expectations are described in:
Required
All repositories in the Crossplane project accept issues and changes from the community through the standard Github workflows:
Both issues and PRs have templates to standardize and guide the contributor experience.
The Contributing guide also describes how changes are accepted, what the contributor can expect to experience, and tips for making a successful contribution.
All communication channels are listed in the main project README: https://github.com/crossplane/crossplane/tree/master?tab=readme-ov-file#get-involved. The most commonly used channels are https://slack.crossplane.io/ and https://github.com/crossplane/crossplane.
All communication channels are listed in the main project README: https://github.com/crossplane/crossplane/tree/master?tab=readme-ov-file#get-involved
All meetings within the Crossplane community and ecosystem are tracked in the community calendar. This calendar as well as other ways to get involved are highlighted prominently in the project's main README.
The Contributing guide describes the process of how to contribute to the project, what the maintainers are expecting, and guidance for how to make a successful contribution.
A similar guide is also available for contributing specifically to the docs at https://docs.crossplane.io/contribute/.
Project health metrics tracked by the CNCF consistently demonstrate that the community has continued to thrive with both adoption of the technology as well as a strong base of contributors to the project:
Engineering Principles
Crossplane is a framework for building cloud native control planes without needing to write code, and the Crossplane project and community is a neutral place for vendors and individuals to come together in enabling these control planes. More details on the project goals/objectives can be found in the official project charter.
We are not aware of any other projects in the landscape that provide the building blocks to build your own custom cloud native control plane that manages all of your infrastructure, or exposes infrastructure resources for application developers through custom defined platform APIs.
The official project charter, explaining what Crossplane is and what it is not, can be found at https://github.com/crossplane/crossplane/blob/master/CHARTER.md.
The Crossplane public roadmap can be found at https://github.com/crossplane/crossplane/blob/master/ROADMAP.md.
The expectations and process for updating the public roadmap over time is outlined in https://github.com/crossplane/crossplane/blob/master/ROADMAP.md.
The Crossplane docs provide an overview of the architecture and components of Crossplane that enable cloud native control planes:
There are also specifications for certain components in Crossplane that inform specific implementations on the expectations and requirements for extending Crossplane:
The original public v0.1 release of Crossplane also included a public vision and architecture document. This document has not kept up with the specific implementation details of Crossplane v1.0+, but is of interest nonetheless: https://docs.google.com/document/d/1whncqdUeU2cATGEJhHvzXWC9xdK29Er45NJeoemxebo/edit?usp=sharing
[x] Document the project's release process and guidelines publicly in a RELEASES.md or equivalent file that defines:
The Crossplane release process and expectations are documented in the following locations:
General overview of the release/patch cycle and LTS policy: https://docs.crossplane.io/latest/learn/release-cycle/
In-depth release process details: https://github.com/crossplane/release/blob/main/README.md
Feature maturity lifecycle: https://docs.crossplane.io/latest/learn/feature-lifecycle/
[x] History of regular, quality releases.
All Crossplane releases and detailed release notes can be found in https://github.com/crossplane/crossplane/releases.
Crossplane follows a quarterly release process as described in the release lifecycle documentation.
The currently supported (eligible for patch releases) releases are listed in the main project README: https://github.com/crossplane/crossplane/blob/master/README.md#releases
Security
Note: this section may be augmented by a joint-assessment performed by TAG Security.
Suggested
- [ ] Achieving OpenSSF Best Practices silver or gold badge.
### Required - [x] **Clearly defined and discoverable process to report security issues.** Crossplane's security and vulnerability disclosure policy is outlined in detail at https://github.com/crossplane/crossplane/security/policy. - [x] **Enforcing Access Control Rules to secure the code base against attacks (Example: two factor authentication enforcement, and/or use of ACL tools.)** The Crossplane organization has enabled the GitHub setting for "Require two-factor authentication for everyone in the Crossplane organization." - [x] **Document assignment of security response roles and how reports are handled.** The response process for security vulnerability disclosure reports is outlined in detail in https://github.com/crossplane/crossplane/security/policy. - [ ] **Document Security Self-Assessment.** The Crossplane maintainer team collaborated with Ada Logics to perform detailed security audits contained in https://github.com/crossplane/crossplane/tree/master/security. - [x] **Third Party Security Review.** - [x] Moderate and low findings from the Third Party Security Review are planned/tracked for resolution as well as overall thematic findings, such as: improving project contribution guide providing a PR review guide to look for memory leaks and other vulnerabilities the project may be susceptible to by design or language choice ensuring adequate test coverage on all PRs. Crossplane completed two separate security audits within 2023, both of which were performed by ADA Logics. The first audit focused on [fuzzing](https://blog.crossplane.io/fuzzing-security-audit/) and was completed in March 2023, followed by a more intense [general security audit](https://blog.crossplane.io/security-audit-2023/) that was broader in scope and completed in July 2023. The full report details can be found in the security folder of the main Crossplane repo: * [Fuzzing audit](https://github.com/crossplane/crossplane/blob/master/security/ADA-fuzzing-audit-22.pdf) * [General security audit](https://github.com/crossplane/crossplane/blob/master/security/ADA-security-audit-23.pdf) In the general security audit, the ADA Logics team identified a total 16 issues, with 7 being deemed Low severity, 8 Medium, and 1 of High severity. All issues were reported in accordance with Crossplane’s responsible disclosure [security policy](https://github.com/crossplane/crossplane/security/policy#reporting-a-vulnerability). CVEs were published for 2 of these 16 issues: * [https://nvd.nist.gov/vuln/detail/CVE-2023-37900](https://nvd.nist.gov/vuln/detail/CVE-2023-37900) * [https://nvd.nist.gov/vuln/detail/CVE-2023-38495](https://nvd.nist.gov/vuln/detail/CVE-2023-38495) At the time of publishing the audit report, 15 of the 16 issues had been fixed in the codebase and patch releases were published for all currently supported versions of Crossplane. The final 16th issue was in alpha code that was subsequently removed, thus resolving 100% of the issues found during the security audit. - [x] **Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge.** Crossplane's OpenSSF Best Practices passing badge can be found at https://www.bestpractices.dev/en/projects/3260. This badge is displayed prominently on the main project [README](https://github.com/crossplane/crossplane/blob/master/README.md). ## Ecosystem ### Suggested N/A ### Required - [x] **Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)** Adopters of the Crossplane project that have chosen to share their adoption story publicly can be found in the [ADOPTERS.md](https://github.com/crossplane/crossplane/blob/master/ADOPTERS.md) file in the main Crossplane repository. Currently, there are over 60 public adopters of the project, and there are more that are willing to share their story with the TOC privately. Some notable Crossplane public adopters include Nike, Autodesk, Grafana, NASA Science Cloud, Elastic, Akamai, SAP, IBM, VMWare Tanzu, and Nokia. - [x] **Used in appropriate capacity by at least 3 independent + indirect/direct adopters, (these are not required to be in the publicly documented list of adopters)** The public Crossplane [adopters list](https://github.com/crossplane/crossplane/blob/master/ADOPTERS.md) explicitly mentions over 25 production use cases. There are additional production users amongst the adopters list that have not explicitly declared their production usage, but depend on Crossplane in production environments nonetheless. The project provided the TOC with a list of adopters for verification of use of the project at the level expected, i.e. production use for graduation, dev/test for incubation. - [ ] **TOC verification of adopters.** Refer to the Adoption portion of this document. - [x] **Clearly documented integrations and/or compatibility with other CNCF projects as well as non-CNCF projects.** * [Kubernetes](https://docs.crossplane.io/latest/getting-started/introduction/) is extended by Crossplane to connect it to external, non-Kubernetes resources, and allows platform teams to build custom Kubernetes APIs to consume those resources. * [Helm](https://docs.crossplane.io/latest/software/install/) is the main way to install Crossplane into a control plane. * [ArgoCD](https://docs.crossplane.io/latest/guides/crossplane-with-argo-cd/) is used frequently to sync Crossplane resources and definitions from a Git repository to the control plane to enable GitOps workflows. * [Flux](https://www.cncf.io/blog/2022/07/26/how-to-apply-gitops-to-everything-with-crossplane-and-flux/) also enables GitOps workflows for Crossplane resources. * [gRPC](https://docs.crossplane.io/latest/concepts/composition-functions/#how-composition-functions-work) powers the communication between Crossplane's core composition engine (client) and the Functions (server) within a user defined composition pipeline. * [Prometheus](https://www.youtube.com/watch?v=GBxfAQnHHbE) metrics provide observability on Crossplane's internal behavior/health as well as statistics about the resources that Crossplane is managing. * [Harbor](https://docs.crossplane.io/latest/concepts/packages/#install-offline) can serve as a container registry for Crossplane [packages](https://docs.crossplane.io/latest/concepts/packages/). * [Open Policy Agent](https://blog.crossplane.io/crossplane-v0-10-compose-and-publish-your-own-infrastructure-crds-velero-backup-restore-compatibility-and-more/) is commonly used with Crossplane to [enforce organizational policy](https://medium.com/edixos/crossplane-in-platform-engineering-becb9414e46) on Crossplane resources. * [Kyverno](https://www.cncf.io/online-programs/cncf-on-demand-webinar-securely-provisioning-cloud-resources-using-kyverno-and-crossplane/) also enforces policy to ensure secure provisioning of resources with Crossplane. * [ArtifactHub](https://artifacthub.io/packages/helm/crossplane/crossplane) indexes all versions of Crossplane's main Helm chart for installation into control planes. * [Backstage](https://2022.platformcon.com/talk/how-to-build-an-idp-with-backstage-crossplane-and-argo-cd) is often used as a developer portal on top of Crossplane to offer a comprehensive Internal Developer Platform. * [Dapr](https://blog.crossplane.io/crossplane-and-dapr/) and Crossplane work well together to expose resources provisioned by Crossplane for consumption by developers with Dapr. * [KubeVela](https://kubevela.io/docs/end-user/components/cloud-services/provision-cloud-resources-by-crossplane/) supports Crossplane as an add-on to provision resources. * [KCL](https://blog.crossplane.io/function-kcl/) has quickly become one of the favored languages to write Crossplane composition logic via [`function-kcl`](https://github.com/crossplane-contrib/function-kcl). * [Velero](https://docs.crossplane.io/latest/guides/disaster-recovery/) can backup and restore the resources of Crossplane to perform disaster recovery. #### Adoption We assume this section will be filled out by the TOC sponsor as the TOC adopter interviews are conducted. There are many Crossplane adopters that can be verified and interviewed in the public [adopters list](https://github.com/crossplane/crossplane/blob/master/ADOPTERS.md). The Crossplane team (@jbw976) will be happy to help find and contact adopters that fit the profiles the TOC sponsor is looking for. ##### Adopter 1 - $COMPANY/$INDUSTRY _If the Adopting organization needs to remain anonymous, stating the industry vertical is sufficient._ MONTH YEAR ##### Adopter 2 - $COMPANY/$INDUSTRY _If the Adopting organization needs to remain anonymous, stating the industry vertical is sufficient._ MONTH YEAR ##### Adopter 3 - $COMPANY/$INDUSTRY _If the Adopting organization needs to remain anonymous, stating the industry vertical is sufficient._ MONTH YEAR