Skip to content

[Graduation] Crossplane Graduation Application #1788

New issue
New issue
Open
Open
[Graduation] Crossplane Graduation Application#1788
Labels
kind/ddProject DD or item related to the DD processlevel/graduationItem related to a graduation level project or the graduation criteria/process itself.toctoc specific issue
@jbw976

Description

@jbw976
jbw976
opened on Jul 22, 2025

Review Project Moving Level Evaluation

  • I have reviewed the TOC's moving level readiness triage guide, ensured the criteria for my project are met before opening this issue, and understand that unmet criteria will result in the project's application being closed.

This Graduation application is a continuation from the previous application #1397. That application was closed as "Not Ready - Will Return" during due diligence with our TOC sponsors @angellk and @dims for the following high level reasons, along with the steps the Crossplane project has taken to resolve them:

  • Vendor Neutrality: The project needs to demonstrate a stronger separation between upstream/downstream concerns and commercial vendors should only appear in an upstream context in accordance with CNCF policies.
    • We have updated all project documentation (e.g., https://docs.crossplane.io/) to refer exclusively to vendor neutral community resources and artifacts.
    • The Crossplane website only mentions vendors in a dedicated commercial page: https://www.crossplane.io/commercial.
    • We established a vendor neutral community registry for Crossplane extension packages (xpkg.crossplane.io) that is hosted in ghcr.io. No vendor associated with the Crossplane project owns or operates this registry.
    • Defined clear policies for Community Extension Projects that enforces publishing of their release artifacts to vendor neutral locations.
    • All vendor specific code has been removed from the upstream code base.
    • These changes were also summarized and broadcasted to the community in this blog post: https://blog.crossplane.io/community-ecosystem/
  • Survivability: The project needs to demonstrate long term survivability and resilience to sponsoring vendors shutting down.
    • We have migrated critical project release processes and artifacts to vendor neutral CNCF owned accounts.
      • If the top supporting vendor were to go out of business, the community could continue to release new versions of the project's software without major obstacles.
    • The vendor neutral community registry (xpkg.crossplane.io) previously mentioned also promotes survivability of the project's extension ecosystem, as their Crossplane package artifacts are published to the neutral registry by default.
    • We have also proactively audited and migrated other project accounts as needed that are not on the critical path for software releases (e.g. community calendar) to vendor neutral CNCF owned accounts.
  • Project Lifecycle Policies: There is confusion around the status and health of Crossplane ecosystem projects which negatively affects the community's ability to adopt the project.
    • We have defined clear governance, policies, and lifecycle for Crossplane's "Community Extension Projects", which includes strict guidelines for project health and archival of projects that are no longer actively maintained.
    • We have worked with extension project maintainers to bring their projects into compliance, and for projects where that is not possible, we have carried out the archival process.

Crossplane Graduation Application

v1.6
This template provides the project with a framework to inform the TOC of their conformance to the Graduation Level Criteria.

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 Extension Projects" in the https://github.com/crossplane-contrib organization. All projects under these organizations fall under the Crossplane governance. Community Extension Projects have specific expectations and lifecyle policies that are defined in the Crossplane governance as well.

Communication: https://slack.crossplane.io/

Project points of contacts:

Graduation Criteria Summary for Crossplane

Application Level Assertion

  • This project is currently Incubating, accepted on 2021-10-12, and applying to Graduate.

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.

Application Process Principles

Suggested

N/A

Required

  • Engage with the domain specific TAG(s) to increase awareness through a presentation or completing a General Technical Review.

Jared Watts (@jbw976) presented Crossplane's graduation proposal and project update to TAG App Delivery on Feb 7, 2024, as noted by @angellk in #1254 (comment).

  • TAG provides insight/recommendation of the project in the context of the landscape

Notes from TAG App Delivery can be found linked from the TAG statement of Crossplane's graduation presentation in #1254 (comment), 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/main/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/main/CHARTER.md#what-crossplane-is

Crossplane is a neutral place for vendors and individuals to come together in enabling control planes.

Since due diligence for our previous graduation application, we have also made numerous changes to improve the project's vendor neutrality, as described in detail at the top of this application, and summarized briefly below:

  • Established a vendor neutral registry for Crossplane extension packages (xpkg.crossplane.io)
  • Updated all project documentation (e.g., https://docs.crossplane.io/) to refer only to vendor neutral resources and artifacts
  • Defined clear governance, policies, and lifecycle for community extension projects, which includes policies around vendor neutrality so that it is enforced consistently throughout the project ecosystem
  • Migrated critical project release artifacts to vendor neutral CNCF owned accounts, improving project sustainability in the face of any vendor shutting down
  • All vendor specific code has been removed from the upstream code base
  • Review and acknowledgement of expectations for graduated projects and requirements for moving forward through the CNCF Maturity levels.
    • Met during the project's original proposal PR Crossplane Graduation Proposal #1254 on 05-Feb-2024, our second application after the format change on 13-Aug-2024, and with our TOC sponsors during due diligence at Kubecon London 31-Mar-2025.

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.

  • Due Diligence Review.

Completion of this due diligence document, resolution of concerns raised, and presented for public comment satisifies the Due Diligence Review criteria.

  • Additional documentation as appropriate for project type, e.g.: installation documentation, end user documentation, reference implementation and/or code samples.

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/main/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

  • Governance has continuously been iterated upon by the project as a result of their experience applying it, with the governance history demonstrating evolution of maturity alongside the project's maturity evolution.

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/main/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.

The most recent important governance update was ratified on 21-Feb-2025 which established the policies for Community Extension Projects: crossplane/crossplane#6290. This was in direct response to feedback on vendor neutrality provided by our TOC sponsors during graduation due diligence for #1397.

Required

  • Clear and discoverable project governance documentation.

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.

  • Governance is up to date with actual project activities, including any meetings, elections, leadership, or approval processes.

The governance is up to date with the latest iteration of the steering committee membership, which was last updated after the most recent election occurred in February 2025: crossplane/crossplane#6304. All processes for approvals, maintainers, conflict resolution, community extension projects, 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/main/GOVERNANCE.md#maximum-representation

Community Extension Projects have clearly defined policies in the project governance that promote vendor neutrality as well, for example the strict requirement that all projects must publish artifacts to the vendor neutral community registry xpkg.crossplane.io: https://github.com/crossplane/crossplane/blob/main/GOVERNANCE.md#policies-for-community-extension-projects

The project charter also reinforces the notion of vendor-neutrality: https://github.com/crossplane/crossplane/blob/main/CHARTER.md#what-crossplane-is

Crossplane is a neutral place for vendors and individuals to come together in enabling control planes.

  • Document how the project makes decisions on leadership roles, contribution acceptance, requests to the CNCF, and changes to governance or project goals.

Changes to governance has a clearly defined process in https://github.com/crossplane/crossplane/blob/main/GOVERNANCE.md#updating-the-governance.

Project leadership (steering committee) election process is defined in https://github.com/crossplane/crossplane/blob/main/GOVERNANCE.md#election-process. This process was followed for the most recent 2025 election.

Process for how each individual repository under the crossplane organization(s) are maintained can be found in https://github.com/crossplane/crossplane/blob/main/GOVERNANCE.md#repository-governance. Additionally, policies and guidelines for Community Extension Projects is clearly defined in https://github.com/crossplane/crossplane/blob/main/GOVERNANCE.md#policies-for-community-extension-projects.

Contribution acceptance is augmented by the contributing guide with https://github.com/crossplane/crossplane/tree/main/contributing#contributing-code and https://github.com/crossplane/crossplane/tree/main/contributing#code-review-process.

  • Document how role, function-based members, or sub-teams are assigned, onboarded, and removed for specific teams (example: Security Response Committee).
  • 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/main/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:

Community Extension Projects must keep these lists up to date, as part of the defined policies and lifecycle expectations.

  • A number of active maintainers which is appropriate to the size and scope of the project.

Across the entire Crossplane project, there are 183 different companies that have committers (individuals with write permissions) on at least one repository.

  • Document a complete maintainer lifecycle process (including roles, onboarding, offboarding, and emeritus status).
  • 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):

  • Project maintainers from at least 2 organizations that demonstrates survivability.

Across the entire Crossplane project, there are 183 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.

  • Code and Doc ownership in Github and elsewhere matches documented governance roles.

Yes, OWNERS.md files in each Crossplane project repository should reflect the documented maintainer roles defined in the governance. For example, https://github.com/crossplane/crossplane/blob/main/OWNERS.md lists current and emeritus maintainers for that repo. The ownership being up to date is an enforced policy for all Community Extension Projects.

  • Document adoption of the CNCF Code of Conduct

Crossplane project and community adhere to the CNCF Code of Conduct, e.g., https://github.com/crossplane/crossplane/blob/main/CODE_OF_CONDUCT.md.

  • CNCF Code of Conduct is cross-linked from other governance documents.

The CNCF Code of Conduct is linked from the root of the core Crossplane repository https://github.com/crossplane/crossplane/blob/main/CODE_OF_CONDUCT.md, where GitHub automatically displays it from its "Code of conduct" tab.

  • All subprojects, if any, are listed.

Crossplane does not have formally defined "subprojects", but all repositories under the crossplane and crossplane-contrib repository adhere to the well defined governance.

  • If the project has subprojects: subproject leadership, contribution, maturity status documented, including add/remove process.

N/A

Contributors and Community

Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy.

Suggested

  • Contributor ladder with multiple roles for contributors.

Contributor roles fall into 3 tiers: member, maintainer, and steering committee. The roles and expectations are described in:

Required

  • Clearly defined and discoverable process to submit issues or changes.

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.

  • Project must have, and document, at least one public communications channel for users and/or contributors.

All communication channels are listed in the main project README: https://github.com/crossplane/crossplane/tree/main?tab=readme-ov-file#get-involved. The most commonly used channels are https://slack.crossplane.io/ and https://github.com/crossplane/crossplane.

  • List and document all project communication channels, including subprojects (mail list/slack/etc.). List any non-public communications channels and what their special purpose is.

All communication channels are listed in the main project README: https://github.com/crossplane/crossplane/tree/main?tab=readme-ov-file#get-involved

  • Up-to-date public meeting schedulers and/or integration with CNCF calendar.

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.

  • Documentation of how to contribute, with increasing detail as the project matures.

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/.

  • Demonstrate contributor activity and recruitment.

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:

  • We are currently in the top 10% of all CNCF projects for contributor authors, at position 13 out of 231
  • This number of PR authors has grown 5x from 184 at the time of Incubation to over 1,000 currently
  • The diversity of companies contributing quadrupled from 105 to 468.
  • The overall number of contributors to the project is now over 3,000.

Engineering Principles

  • Document project goals and objectives that illustrate the project’s differentiation in the Cloud Native landscape as well as outlines how this project fulfills an outstanding need and/or solves a problem differently. This requirement may also be satisfied by completing a General Technical Review.

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.

  • Document what the project does, and why it does it - including viable cloud native use cases. This requirement may also be satisfied by completing a General Technical Review.

The official project charter, explaining what Crossplane is and what it is not, can be found at https://github.com/crossplane/crossplane/blob/main/CHARTER.md.

  • Document and maintain a public roadmap or other forward looking planning document or tracking mechanism.

The Crossplane public roadmap can be found at https://github.com/crossplane/crossplane/blob/main/ROADMAP.md.

  • Roadmap change process is documented.

The expectations and process for updating the public roadmap over time is outlined in https://github.com/crossplane/crossplane/blob/main/ROADMAP.md.

  • Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation. This requirement may also be satisfied by completing a General Technical Review and capturing the output in the project's documentation.

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

  • Document the project's release process and guidelines publicly in a RELEASES.md or equivalent file that defines:

    • Release expectations (scheduled or based on feature implementation)
    • Tagging as stable, unstable, and security related releases
    • Information on branch and tag strategies
    • Branch and platform support and length of support
    • Artifacts included in the release.
    • Additional information on topics such as LTS and edge releases are optional. Release expectations are a social contract between the project and its end users and hence changes to these should be well thought out, discussed, socialized and as necessary agreed upon by project leadership before getting rolled out.

The Crossplane release process and expectations are documented in the following locations:

  • History of regular, quality 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

  • 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.

  • 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.".

  • 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.

A security self-assessment has been published to the security folder in the main Crossplane repository at https://github.com/crossplane/crossplane/blob/main/security/self-assessment.md. If needed, we are happy to move the assessment content to a different long term home if required.

  • Third Party Security Review.

    • 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 and was completed in March 2023, followed by a more intense general security audit 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:

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. CVEs were published for 2 of these 16 issues:

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.

  • 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.

Ecosystem

Suggested

N/A

Required

  • 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 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.

  • 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 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.

  • Clearly documented integrations and/or compatibility with other CNCF projects as well as non-CNCF projects.
  • Kubernetes 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 is the main way to install Crossplane into a control plane.
  • ArgoCD is used frequently to sync Crossplane resources and definitions from a Git repository to the control plane to enable GitOps workflows.
  • Flux also enables GitOps workflows for Crossplane resources.
  • gRPC powers the communication between Crossplane's core composition engine (client) and the Functions (server) within a user defined composition pipeline.
  • Prometheus metrics provide observability on Crossplane's internal behavior/health as well as statistics about the resources that Crossplane is managing.
  • Harbor can serve as a container registry for Crossplane packages.
  • Open Policy Agent is commonly used with Crossplane to enforce organizational policy on Crossplane resources.
  • Kyverno also enforces policy to ensure secure provisioning of resources with Crossplane.
  • ArtifactHub indexes all versions of Crossplane's main Helm chart for installation into control planes.
  • Backstage is often used as a developer portal on top of Crossplane to offer a comprehensive Internal Developer Platform.
  • Dapr and Crossplane work well together to expose resources provisioned by Crossplane for consumption by developers with Dapr.
  • KubeVela supports Crossplane as an add-on to provision resources.
  • KCL has quickly become one of the favored languages to write Crossplane composition logic via function-kcl.
  • Velero can backup and restore the resources of Crossplane to perform disaster recovery.
  • K8GB documents how to use Crossplane to build resilient, scalable multicluster environments integrated with k8gb for DNS-based failover.

Adoption

We assume this section will be filled out by the TOC sponsor as the TOC adopter interviews are conducted. The Crossplane team has previously submitted multiple adopter interview contact details.

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    kind/ddProject DD or item related to the DD processlevel/graduationItem related to a graduation level project or the graduation criteria/process itself.toctoc specific issue

    Type

    No type

    Projects

    CNCF TOC Board

    Status

    Not Ready-Will Return

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions