KMP support for n-versions of certificates\keys

[duffney]

What would you like to be added?

It would be helpful to add support for handling multiple versions of certificates or keys when validating artifacts. As part of this feature, it would be great if we could configure a single certificate or key with multiple versions. The system could then iterate through these versions to ensure that each is still valid and use them to verify the artifact. This functionality would be particularly useful for environments where secret rotation is common, as it would allow us to validate artifacts signed by both current and previous (but still valid) versions of certificates or keys.

Anything else you would like to add?

No response

Are you willing to submit PRs to contribute to this feature?

• Yes, I am willing to implement it.

[duffney]

After looking into this a bit more, I found out that it is technically possible to define multiple versions of a certificate from AKV with the KMP resource by doing the following:

apiVersion: config.ratify.deislabs.io/v1beta1
kind: KeyManagementProvider
metadata:
  name: keymanagementprovider-akv
spec:
  type: azurekeyvault
  parameters:
    vaultURI: https://yourkeyvault.vault.azure.net/
    certificates:
      - name: yourCertName
        version: yourCertVersion 
      - name: yourCertName
        version: yourCertVersion2
    tenantID:
    clientID:

When you create a new "version" of a certificate in AKV, it generates an entirely new certificate. The only relationship to the previous version is the shared name and a visible relationship in the Azure Portal UI. This means adding multiple versions is straightforward: you simply add another certificate and update the version to uniquely identify the one you want to include.

If that's acceptable, I don't think any additional work is required to implement this because that functionality exists. And the only work todo would be to document how to add multiple versions of a certificate and point out that each version of a cert in AKV is actually a different certificate.

To make things more user friendly, it code could be modified to support something likes this that allows you to input multiple versions under a single certificate name. From my poking around the code base, it seems like there'd be some changed need at the KMP and AKV provider level to support it.

apiVersion: config.ratify.deislabs.io/v1beta1
kind: KeyManagementProvider
metadata:
  name: keymanagementprovider-akv
spec:
  type: azurekeyvault
  parameters:
    vaultURI: https://yourkeyvault.vault.azure.net/
    certificates:
      - name: yourCertName
        versions: 
          - yourCertVersion1
          - yourCertVersion2
    tenantID:
    clientID: