My recommendation would be to create a new tracking issue and a new KEP using the latest template in k/enhancements. The old KEP can be marked as withdrawn as a historical artifact, but any consensus we had ~3 years ago is long gone. The KEP process has changed and matured since then considerably. Also take a look at [1] since that had many outstanding comments that were never addressed.
On the new KEP, I think the most important section would be the production readiness review bits (PRR). For example, this API is inline to pod creates and would break a cluster pretty fundamentally if the signer was offline.
Some other high level thoughts:
- By default, all pods gets SA tokens that are auto refreshed by the kubelet which will stress the signer
- There could be increased start time of pods due to signer latency
- I believe the API server must retain control over the payload to keep SA tokens compatible across all environments
- There should be some kind of status API (see KMS v2 as an example)
- All signing operations should return the key_id that was used
- We would want a UID per operation for tracing
- Include metrics for debugging
- A complete reference implementation should be part of the graduation criteria
- The API and/or the reference implementation should support a mode where not all signing operations require external calls to a remote KMS - this would need to work generically across all environments with HA API servers (and no reliance on anything external other than the remote KMS - the plugin itself is stateless)