search

cncf / toc

⚖️ The CNCF Technical Oversight Committee (TOC) is the technical governing body of the CNCF Foundation.
https://cncf.io
1.65k stars 627 forks source link

[Graduation] cert-manager Graduation Application #1306

Open SgtCoDFish opened 2 months ago

SgtCoDFish commented 2 months ago

cert-manager Graduation Application

@kgamanji suggested we raise this issue to replace the PR we raised initially (#1212), as the process for graduation has changed since we raised that PR.

Project Repo(s): https://github.com/cert-manager/cert-manager (and others under https://github.com/cert-manager) Project Site: https://cert-manager.io/ Sub-Projects: trust-manager, approver-policy, csi-driver, csi-driver-spiffe, istio-csr Communication: Kubernetes slack (#cert-manager-dev), regular meetings, mailing list (cert-manager-maintainers@googlegroups.com)

Project points of contact:

Graduation Criteria Summary for cert-manager

Adoption Assertion

The project has been adopted by the following organizations in a testing and integration or production capacity:

Criteria

Application Process Principles

Suggested

N/A

Required

TAG-security suggested that a joint assessment would be helpful following our self assessment, to broaden the docs we have around security. We'll engage in that process as the self-assessment completes.

All questions we received during the TAG security meeting were answered and nobody on the call had any red flags about cert-manager.

The self assessment can be viewed in the tag-security repo.

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

## Governance and Maintainers Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy. ### Suggested - [x] **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.** We've looked to expand our governance and we're looking to continue expanding it ### Required - [x] **Clear and discoverable project governance documentation.** https://github.com/cert-manager/community/blob/main/GOVERNANCE.md - [x] **Governance is up to date with actual project activities, including any meetings, elections, leadership, or approval processes.** This was a WIP item for us, but our current governance docs are up to date. We might iterate more on spefically the steering committee stuff, but we've now had a steering committee meeting and iterated on our roadmap from that. - [x] **Governance clearly documents [vendor-neutrality](https://contribute.cncf.io/maintainers/community/vendor-neutrality/) of project direction.** Most of our decisions today are made by maintainers who're actively involved in the project, and we've set out a clear path for people to become maintainers. We have maintainers spread across several companies and we'd gladly accept more. Our roadmap is based on (and links to) [this document](https://contribute.cncf.io/maintainers/community/contributor-growth-framework/open-source-roadmaps/#components-of-a-typical-roadmap) which has vendor neutrality at its core. - [x] **Document how the project makes decisions on leadership roles, contribution acceptance, requests to the CNCF, and changes to governance or project goals.** This is included in our governance docs and in our docs for contributors. See for example our [feature policy](https://cert-manager.io/docs/contributing/policy/). - [x] **Document how role, function-based members, or sub-teams are assigned, onboarded, and removed for specific teams (example: Security Response Committee).** - [x] **Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.** All maintainers share all domains of responsbility currently. List [here](https://github.com/cert-manager/community/blob/main/maintainers.csv). - [x] **A number of active maintainers which is appropriate to the size and scope of the project.** Our maintainer list currently lists 8 maintainers, with the expectation that at least one more will be onboarded soon. - [x] **Document a complete maintainer lifecycle process (including roles, onboarding, offboarding, and emeritus status).** Documented in [GOVERNANCE.md](https://github.com/cert-manager/community/blob/4d35a69437d21b76322157e6284be4cd64e6d2b7/GOVERNANCE.md#maintainer). - [x] **Demonstrate usage of the maintainer lifecycle with outcomes, either through the addition or replacement of maintainers as project events have required.** We've moved a couple of maintainers to emeritus status as they've drifted away from the project. We're hoping to onboard at least one a new maintainer soon to test our documented processes, and we have at least three people on the path to becoming maintainers. - [x] **Project maintainers from at least 2 organizations that demonstrates survivability.** Currently Venafi, Diagrid, Tailscale and G-Research. - [x] **Code and Doc ownership in Github and elsewhere matches documented governance roles.** This is documented in the governance process too. Maintainers get roles in GCP for managing test / release infra, and maintainers get elevated privileges in the GitHub org. - [x] **Document agreement that project will adopt CNCF Code of Conduct.** We've operated under the CNCF CoC for years. - [x] **CNCF Code of Conduct is cross-linked from other governance documents.** It's one of the first requirements we have to become a contributor: https://github.com/cert-manager/community/blob/4d35a69437d21b76322157e6284be4cd64e6d2b7/GOVERNANCE.md#contributor - [x] **All subprojects, if any, are listed.** We list them in the website, usually mentioning them when they're appropriate too. - [x] **If the project has subprojects: subproject leadership, contribution, maturity status documented, including add/remove process.** Mentioned at the beginning of our governance docs: > This governance charter applies to every project under the cert-manager GitHub organisation. The term "cert-manager project" refers to any work done under the cert-manager GitHub organisation and includes the cert-manager/cert-manager repository itself as well as cert-manager/trust-manager, cert-manager/approver-policy and all the other repositories under the cert-manager GitHub organisation. ## Contributors and Community Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy. ### Suggested - [x] **Contributor ladder with multiple roles for contributors.** Clearly defined in governance docs: https://github.com/cert-manager/community/blob/4d35a69437d21b76322157e6284be4cd64e6d2b7/GOVERNANCE.md#cert-manager-governance ### Required - [x] **Clearly defined and discoverable process to submit issues or changes.** GitHub issues / PRs. We have a [policy](https://cert-manager.io/docs/contributing/policy/) so people know what to expect when they want to propose a bigger change. - [x] **Project must have, and document, at least one public communications channel for users and/or contributors.** We have several, listed at the top of this issue. - [x] **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 listed [here](https://cert-manager.io/docs/contributing/). - [x] **Up-to-date public meeting schedulers and/or integration with CNCF calendar.** We have an up-to-date meeting schedule [on our website](https://cert-manager.io/docs/contributing/#meetings). As a result of raising this issue, I've reached out to the CNCF to look to include our events on the public CNCF calendar. UPDATE 2024-05-02: We [have now integrated with the CNCF calendar](https://kubernetes.slack.com/archives/CDEQJ0Q8M/p1714629543170069) for our biweekly meeting, thanks to @maelvls! - [x] **Documentation of how to contribute, with increasing detail as the project matures.** Details [here](https://cert-manager.io/docs/contributing/contributing-flow/) and in other places on the website. - [x] **Demonstrate contributor activity and recruitment.** We regularly onboard new contributors, and each minor cert-manager release contains a thank-you list of who was involved. For example, the alpha release of the next minor release already lists 10 contributors and that will continue to grow: https://github.com/cert-manager/cert-manager/releases/tag/v1.15.0-alpha.0 ## Engineering Principles - [x] **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.** The first line of every cert-manager release re-states the ambition we have: > cert-manager is the easiest way to automatically manage certificates in Kubernetes and OpenShift clusters. We've become essentially the standard for managing certificates in a cloud-native (kubernetes-native) way. - [x] **Document what the project does, and why it does it - including viable cloud native use cases.** Extensive documentation on https://cert-manager.io/docs/ - [x] **Document and maintain a public roadmap or other forward looking planning document or tracking mechanism.** We've iterated on the old roadmap along with the steering committee and moved it into the community repo: https://github.com/cert-manager/community/blob/fb1a2477406f4ce563b7ec5044049d29dc79e1d6/ROADMAP.md - [x] **Roadmap change process is documented.** This is going through review currently by community members and members of the steering committee: https://github.com/cert-manager/community/pull/28 - [x] **Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation.** Also available in project [docs](https://cert-manager.io/docs/) - [x] **Document the project's release process and guidelines publicly in a RELEASES.md or equivalent file that defines:** - [x] Release expectations (scheduled or based on feature implementation) - [x] Tagging as stable, unstable, and security related releases - [x] Information on branch and tag strategies - [x] Branch and platform support and length of support - [x] 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. Our release process is documented on [the website](https://cert-manager.io/docs/contributing/release-process/) and our support schedule is documented on a [different page](https://cert-manager.io/docs/releases/). The release process has been updated to reflect recent changes which mean that any maintainer can do a release, and that it's no longer a requirement to be a Venafi employee. It's worth pointing out that there is still one thing which requires approval of a Venafi employee - that's to publish the Helm chart to charts.jetstack.io which is difficult to change since that repo is so widely used. We intend to provide an alternative install mechanism (likely an OCI registry) in the near future. - [x] **History of regular, quality releases.** Our [supported releases](https://cert-manager.io/docs/releases/) page lists our extensive release history for cert-manager. ## Security Note: this section may be augemented by a joint-assessment performed by TAG Security. ### Suggested - **Achieving OpenSSF Best Practices silver or gold badge.** We'll look into this down the road but it's not an immediate priority for us. ### Required - [x] **Clearly defined and discoverable process to report security issues.** SECURITY.md file in all relevant repos, with a mailing list we watch for reports. - [x] **Enforcing Access Control Rules to secure the code base against attacks (Example: two factor authentication enforcement, and/or use of ACL tools.)** 2FA required for GitHub org members. - [x] **Document assignment of security response roles and how reports are handled.** This applies to all maintainers and our [org security policy](https://github.com/cert-manager/community/blob/main/SECURITY.md) is quite detailed. - [x] **Document Security Self-Assessment.** [Document here](https://docs.google.com/document/d/1Sl1SqYbPSbBMoZroBU8M1dMw5DN-uUgoR1KLHoo5tr0/edit?usp=sharing). This has been worked on alongside TAG security. We intend to complete this and merge it to the TAG security repo. - [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. Completed, see [announcement](https://cert-manager.io/announcements/2024/03/18/cert-manager-security-audit/) - [x] **Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge.** https://www.bestpractices.dev/en/projects/8079 - badge linked in cert-manager/cert-manager ## Ecosystem ### Suggested N/A ### Required - [x] **Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)** Quite out of date but we have one: https://github.com/cert-manager/community/blob/main/USERS.md We're looking to expand this as part of the graduation process - [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)** Used by a few orders of magnitude more adopters than 3! 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.** We've added 6 users to the internal graduation google doc who've all agreed to be interviewed. 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.** Our docs are clear around Kubernetes integrations (since that's our primary integration). We also document integrations with Hashicorp Vault, Let's Encrypt, tens of other issuers, SPIFFE (via csi-driver-spiffe) and a huge variety of cloud DNS providers. #### Adoption ##### 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
kgamanji commented 2 months ago

On 23/04, cert-manager maintainers and I had the kick-off meeting for the graduation process. Here are the suggested action items:

SgtCoDFish commented 1 month ago

@kgamanji I've updated the description of this issue to reflect the status today. I think we've now ticked off everything we needed to, and I think everything in your follow-up comment is addressed as well!

I think we're ready for the next step now!