
- To learn the rationale behind a change (e.g., why service account tokens moved from automatic Secrets to on-demand tokens).
- To see design decisions, implementation plans, testing strategies, and graduation criteria.
- To find the authoritative record of how a change should behave across versions.
- KEPs provide a structured, reviewable format that SIGs can approve or reject consistently.
- They support long-lived documentation (goals, non-goals, test plans, graduation criteria) that is hard to maintain in issues.
- Issues are flat and easily proliferate; KEPs give structure for tracking multi-release work and formalizing SIG intent.
KEPs are not a replacement for issues or pull requests; they complement them. Use a KEP when a proposal needs design, rationale, test plans, and defined graduation criteria beyond a simple issue.
KEP structure and naming
Every KEP follows a naming convention and must be well-documented. Typical KEP sections include:
KEPs are organized under SIG directories. SIGs focus on areas like applications, cluster lifecycle, networking, storage, and security. Each SIG maintains a KEP directory where proposals relevant to that SIG are stored and managed.

Example: Kubernetes Dry-Run KEP
The dry-run feature began as a KEP. It specifies:- Which API verbs and endpoints support dry-run.
- How kubectl should expose the CLI behavior.
- A test plan and graduation criteria.
--dry-run flag:
Note: The KEP documents that an empty
--dry-run value is deprecated and will require an explicit value in a future release. Pay attention to deprecation warnings and upgrade guidance in the KEP.Example: Bound Service Account Tokens (KEP 1205)
KEP 1205 introduced bound service account tokens and the TokenRequest API to address several security issues:- Non-audience-bound JWTs could be replayed in other contexts.
- Automatically provisioning service account tokens created many Secrets and increased attack surface.
- Long-lived tokens were hard to rotate; stolen tokens could provide prolonged access.


KEP lifecycle
KEPs are explicitly tracked through defined lifecycle stages so the community knows the current state and expectations.
Each KEP should document the criteria for moving between stages (for example, tests required to move from alpha to beta, or graduation criteria to reach GA).
Resources and further reading
- KEP repository: https://github.com/kubernetes/enhancements
- Kubernetes documentation: https://kubernetes.io/docs/
- TokenRequest KEP (KEP 1205): https://github.com/kubernetes/enhancements/tree/master/keps/sig-auth/1205-bound-service-account-tokens