K8sGateway Incubation Application

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

Project Repo(s): https://github.com/k8sgateway/k8sgateway, https://github.com/k8sgateway/community

Project Site: https://k8sgateway.io

Sub-Projects: NA

Communication: https://cloud-native.slack.com/archives/C080D3PJMS4

Project points of contacts: Idit Levine, Lin Sun, Yuval Kohavi

• (Post Incubation only) Book a meeting with CNCF staff to understand project benefits and event resources.

Incubation Criteria Summary for K8sGateway

Application Level Assertion

• This project is currently Sandbox, accepted on YYYYMMDD, and applying to Incubation.
• This project is applying to join the CNCF at the Incubation level.

Adoption Assertion

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

• https://k8sgateway.io/#users

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.
  • This was completed and occurred on DD-MMM-YYYY, and can be discovered at $LINK.

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

• All project metadata and resources are vendor-neutral.

• Review and acknowledgement of expectations for Sandbox projects and requirements for moving forward through the CNCF Maturity levels.
• Met during Project's application on DD-MMM-YYYY.

• Due Diligence Review.

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.

Governance and Maintainers

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

Suggested

• Clear and discoverable project governance documentation.

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

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

• Governance clearly documents vendor-neutrality of project direction.

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

• Document how role, function-based members, or sub-teams are assigned, onboarded, and removed for specific teams (example: Security Response Committee).

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

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

Required

• Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.

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

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

  • https://github.com/k8sgateway/community/blob/main/CODE-OF-CONDUCT.md

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

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.

Required

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

  • https://github.com/k8sgateway/community/blob/main/CONTRIBUTING.md

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

  • https://github.com/k8sgateway/community?tab=readme-ov-file#communication-channels

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

  • https://github.com/k8sgateway/community?tab=readme-ov-file#communication-channels
  • https://k8sgateway.io/docs/reference/vulnerabilities/#-where-to-report

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

  • We use a google calendar to track the community meeting schedule, https://calendar.google.com/calendar/u/1?cid=ZDI0MzgzOWExMGYwMzAxZjVkYjQ0YTU0NmQ1MDJmODA5YTBjZDcwZGI4ZTBhZGNhMzIwYWRlZjJkOTQ4MzU5Y0Bncm91cC5jYWxlbmRhci5nb29nbGUuY29t

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

  • https://github.com/k8sgateway/community/blob/main/CONTRIBUTING.md

• Demonstrate contributor activity and recruitment.

Engineering Principles

Suggested

• Roadmap change process is documented.

  • https://github.com/k8sgateway/community/blob/main/ROADMAP.md#updating-the-roadmap

• History of regular, quality releases.

  • https://github.com/k8sgateway/k8sgateway/releases

Required

• 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 can also be satisfied by completing a General Technical Review.

  • https://github.com/k8sgateway/k8sgateway?tab=readme-ov-file#what-makes-k8sgateway-unique

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

  • https://k8sgateway.io/docs/about/overview/

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

  • https://github.com/k8sgateway/community/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 can also be satisfied by completing a General Technical Review and capturing the output in the project's documentation.

  • https://k8sgateway.io/docs/about/architecture/ (architecture)
  • https://k8sgateway.io/docs/about/deployment-patterns/ (use cases)

• Document the project's release process.

Security

Note: this section may be augmented by a joint-assessment performed by TAG Security.

Suggested

N/A

Required

• Clearly defined and discoverable process to report security issues.

  • https://k8sgateway.io/docs/reference/vulnerabilities/

• Enforcing Access Control Rules to secure the code base against attacks (Example: two factor authentication enforcement, and/or use of ACL tools.)

  • k8sgateway requires 2 factor authentication for the entire

• Document assignment of security response roles and how reports are handled.

  • https://k8sgateway.io/docs/reference/vulnerabilities/

• Document Security Self-Assessment.

• Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge.

Ecosystem

Suggested

N/A

Required

• Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)

  • https://k8sgateway.io/#users

• 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 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.
  • https://k8sgateway.io/docs/integrations/

Additional Information