Many versions of one secret in Key Vault

[jasperkpi]

Is your feature request related to a problem? Please describe. I'm using Azure Key Vault for API keys that rotate every 10 minutes. It uses an OAuth2 flow, where the access_token is valid for 600 seconds. We safe the new refresh_token that is generated every rotation in the key vault. This means I have secrets with as much as 20.000 versions. When I use the SecretClient.list_properties_of_secret_versions it takes minutes to load all the versions. Is there any way to fix this?

Describe the solution you'd like How can I prevent having to load so many versions? I try to get the latest 10 versions, not all 20k.

Describe alternatives you've considered I've considered:

• Deleting old versions, which seems not to be possible. There's no "retention time" for versions. Only completely soft-delete the secret manually and rewrite as the same name - maybe?
• Sorting the request, but versions don't come date-sorted on the Get Secret Versions as I've found. They come hexadecimally sorted based on the version id, which is kinda useless?

I don't care there are 20k versions, I'm fine Azure apparently wants to keep them. I just want to view the last 10 or so. How would this be possible? Am I forgetting about an option? Thanks.

[github-actions[bot]]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @jlichwa @RandalliLama @schaabs.

[mccoyp]

Hi @jasperkpi, thank you for opening an issue -- I see how this scenario could be frustrating. @jlichwa, do you know if there's an option on the service's end to restrict the number of results we get from this operation?

[mccoyp]

@jasperkpi I tried reproducing your issue and found the same behavior; iterating over the full set of versions (after I had created 20,000) took a long time, and the sorting was deterministic but not chronological.

If your primary goal is just to get a small batch of secret versions for inspection, I would recommend using the by_page() method on the ItemPaged object you get back from list_properties_of_secret_versions. This will group the response into smaller pages that can be rapidly inspected. For example:

versions = client.list_properties_of_secret_versions(secret_name)
pages = versions.by_page()
single_page = next(pages)
for secret_properties in single_page:
    print(secret_properties.version)

The default page size is 25 entries, but you can change this by passing a smaller integer through a max_page_size keyword argument to list_properties_of_secret_versions.

If you specifically need the most recent versions of the secret, this seems to unfortunately require manual sorting (unless @jlichwa can comment on an alternative once he's back in the office). The other alternative could be to create new secrets instead of a new version of the same secret, though I understand how having a single secret name could be a requirement for shared referencing and simplicity.

[github-actions[bot]]

Hi @jasperkpi. Thank you for opening this issue and giving us the opportunity to assist. To help our team better understand your issue and the details of your scenario please provide a response to the question asked above or the information requested above. This will help us more accurately address your issue.

[jasperkpi]

@mccoyp Thanks for your answer. I thought this would be the case. Unfortunately, I am looking for the most recent versions just to recover the not-current-but-last key. So only the recent 2 or 3 would be enough... This now means I have to get all 17.000 secret versions (with a OAuth refresh time of 10 minutes, versions are made at a rapid pace) and then sort them on changeddate.

versionlist = []
versions = client.list_properties_of_secret_versions(secret_name)
for version in versions:
    versionlist += [f'{str(version.created_on)[:19]} {{{version.version}}} ']
sortedversionlist = sorted(versionlist, reverse=1)

I just hoped I was completely missing out a function of list_properties_of_secret_versions that delivered a sorted list or something. Thanks!

[mccoyp]

@jasperkpi it may be more performant to use metadata, such as tags, to record recent versions of the secret. That way you could fetch the most recent version of the key, inspect the tags, and then fetch the specific versions that are recorded. It would require multiple service requests, but it may save time overall.

I did discuss this with the service team and chronological version sorting unfortunately doesn't appear to be an option at this time. I'll mark this issue as resolved, but we'll be sure to incorporate this feedback into future planning. Thank you again for opening an issue!

[github-actions[bot]]

Hi @jasperkpi. Thank you for opening this issue and giving us the opportunity to assist. We believe that this has been addressed. If you feel that further discussion is needed, please add a comment with the text "/unresolve" to remove the "issue-addressed" label and continue the conversation.

[github-actions[bot]]

Hi @jasperkpi, since you haven’t asked that we /unresolve the issue, we’ll close this out. If you believe further discussion is needed, please add a comment /unresolve to reopen the issue.