search

kyverno / KDP

Kyverno Design Proposals
Apache License 2.0
16 stars 25 forks source link

readme

Kyverno Design Proposals

This repository is used to manage Kyverno Design Proposals (KDPs). A design proposal is recommend for any significant change, including new features and enhancements.

Older proposals were managed in documents. All new proposals should be submitted as a PR: https://github.com/kyverno/KDP/pulls.

Active Proposals

Name Status Release
Foreach Implemented 1.5
Dynamic Webhooks Implemented 1.5
Image Signature Verification Implemented 1.6
Image Attestations Implemented 1.6
Internal Auto-Gen Rules Implemented 1.7
Generate on existing Implemented 1.7
Mutate on existing Implemented 1.7
CLI test generate policies Implemented 1.7
Image Verification Refectoring Implemented 1.7
Extending Pod Security Admission Implemented 1.8
YAML Signing and Verification Implemented 1.8
Report Aggregation Implemented 1.8
Store Kyverno policies in OCI registries Implemented 1.9
Policy Exceptions In Review 1.9
ConfigMap cache enhancement with Informers Implemented 1.9

Inactive Proposals

Name Status
SBOM Policy Rejected

KDP Process

Proposal

To get a proposal into Kyverno, first, a KDP needs to be merged into the KDP repo. Once an KDP is merged, it's considered 'Accepted' and may be 'Implemented' to be included in the project. These steps will get an KDP to be considered:

  1. Fork the KDP repo: https://github.com/kyverno/KDP
  2. Copy template.md to proposals/feature.md (where 'my-feature' is descriptive.).
  3. Fill in KDP. Any section can be marked as "N/A" if not applicable.
  4. Submit a pull request. The pull request is the time to get review of the proposal from the larger community.
  5. Build consensus and integrate feedback. KDPs that have broad support are much more likely to make progress than those that don't receive any comments.
  6. Once the pull request is approved by two maintainers, the KDP will enter the 'Final Comment Period'.

Final Comment Period

When a pull request enters FCP the following will happen:

  1. A maintainer will apply the "Final Comment Period" label.
  2. The FCP will last 7 days. If there's unanimous agreement amongst the maintainers the FCP can close early.
  3. For voting, the binding votes are comprised of the maintainers. Acceptance requires majority of binding votes in favor. The absence of a vote from a party with a binding vote in the process is considered to be a vote in the affirmative. Non-binding votes are of course welcome.
  4. If no substantial new arguments or ideas are raised, the FCP will follow the outcome decided. If there are substantial new arguments, then the KDP will go back into development.