Disabled keys in AKV should not be used for Cosign signature verification
yizha1 opened this issue · 3 comments
What happened in your environment?
I created a key in AKV and used the latest version (version-1) to sign container images. Later on, I found there were some issues with the version-1, then I rotated the key and got a new version (version-2) of the key. I disabled version-1 in AKV. However, I can still configure keymanagementprovider to use version-1, and the signature verification still passed.
What did you expect to happen?
The disabled version (version-1) should not be used for signature verification.
What version of Kubernetes are you running?
AKS
What version of Ratify are you running?
0-dev (dev.20240505.6163b7e)
Anything else you would like to add?
Currently, Ratify does not automatically reconcile keys on a regular basis unless there is a failure during the initial setup of keys in the keymanagementprovider. When this enhancement is supported, Ratify will be able to retrieve all versions of a key from Azure Key Vault (AKV), excluding any disabled or expired keys.
Are you willing to submit PRs to contribute to this bug fix?
- Yes, I am willing to implement it.
@yizha1 do we want to extend this to include expired keys? How about disabled certificates?
@akashsinghal sorry for late response, although the issue was closed. Based on my research, expired keys are not allowed for Cosign signing (Keys are managed in AKV), in other words, if an image is signed with Cosign using keys in AKV, the key should be valid in AKV during signing. So expired versions of keys should be allowed for verification. If there is an issue with the expired key, users should disable the version of key, and a disabled version of key is not allowed for verification. For certificate, if it is disabled, it should not be used for verification as well. The certificate expiry is a bit different, which will be following the procedure of timestamping.