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.
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 |
Name | Status |
---|---|
SBOM Policy | Rejected |
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:
- Fork the KDP repo: https://github.com/kyverno/KDP
- Copy
template.md
toproposals/feature.md
(where 'my-feature' is descriptive.). - Fill in KDP. Any section can be marked as "N/A" if not applicable.
- Submit a pull request. The pull request is the time to get review of the proposal from the larger community.
- 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.
- Once the pull request is approved by two maintainers, the KDP will enter the 'Final Comment Period'.
When a pull request enters FCP the following will happen:
- A maintainer will apply the "Final Comment Period" label.
- The FCP will last 7 days. If there's unanimous agreement amongst the maintainers the FCP can close early.
- 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.
- 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.