Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[Graduation] Crossplane Graduation Application #1397

Open
50 of 53 tasks
jbw976 opened this issue Aug 17, 2024 · 0 comments
Open
50 of 53 tasks

[Graduation] Crossplane Graduation Application #1397

jbw976 opened this issue Aug 17, 2024 · 0 comments
Labels
graduation tag-app-delivery

Comments

@jbw976
Copy link
Contributor

jbw976 commented Aug 17, 2024

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 #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

  • Give a presentation and engage with the domain specific TAG(s) to increase awareness

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

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

  • Review and acknowledgement of expectations for graduated projects and requirements for moving forward through the CNCF Maturity levels.

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.

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

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

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

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

  • 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/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:

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

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

  • 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/master/OWNERS.md.

  • Document agreement that project will adopt CNCF Code of Conduct.

Crossplane project and community adhere to the CNCF Code of Conduct, e.g., https://github.com/crossplane/crossplane/blob/master/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/master/CODE_OF_CONDUCT.md

  • 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/master?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/master?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 12 out of 190
  • This number of PR authors has grown 4x from 184 at the time of Incubation to over 799 currently
  • The diversity of companies contributing also quadrupled from 105 to 395.
  • The overall number of contributors to the project is now almost 2,400.

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.

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.

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.

  • 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/master/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/master/ROADMAP.md.

  • Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of 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.

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

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

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. 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
graduation tag-app-delivery
Projects
CNCF TOC Board
Status: New
Milestone
No milestone
Development

No branches or pull requests
2 participants
@angellk @jbw976