Allow setting Azure Key Vault API version in ClientOptions for Secrets, Keys and Certificates

[nagyesta]

Feature Request

When a new client version is released because support is added to a new Azure Key Vault API version (like in case of the recently added 7.5 API support), the default API version is always the latest.

Since setting API Version is not possible, I am not able to continue using the 7.4 API if I want to.

I have tried setting the APi version like this:

httpClient := prepareClient()
cred, _ := azidentity.NewDefaultAzureCredential(nil) // Will use Managed Identity via the Assumed Identity container
client, _ := azcertificates.NewClient("https://localhost:8443",
    cred,
    &azcertificates.ClientOptions{ClientOptions: struct {
        APIVersion       string
        Cloud            cloud.Configuration
        Logging          policy.LogOptions
        Retry            policy.RetryOptions
        Telemetry        policy.TelemetryOptions
        TracingProvider  tracing.Provider
        Transport        policy.Transporter
        PerCallPolicies  []policy.Policy
        PerRetryPolicies []policy.Policy
    }{APIVersion: "7.4", Transport: &httpClient}, DisableChallengeResourceVerification: true})

Which generated this error:

failed to get the secret: this client doesn't support overriding its API version

Assuming, that this is the intended way to set the API version, could you please add support to API version overrides?

I can understand if it can be only set to certain values ("7.2", "7.3", "7.4", "7.5", etc.), but it would help me reduce the number of times my build breaks if I had a way to set the API version to not use latest.

Would this be possible?

Thank you in advance!

[gracewilcox]

Hi @nagyesta! With each release we generate from a specific service version. Could you use an older version of the SDK? For example, if you need to use service version 7.4 you can use v1.0.0 of the SDK.

Is there a particular reason why you need this feature? There shouldn't be any breaking changes between minor version releases of the SDK.

[github-actions[bot]]

Hi @nagyesta. 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.

[nagyesta]

Hi @gracewilcox , thank you for looking into this and thank you for the additional details!

I realize, that my case might be fairly uncommon and I should have shared more context to make it more compelling. Sorry for not doing so in my initial post!

I need this feature, because I am the developer of an Azure Key Vault test double. As part of this effort, I am providing example code, just like the snippet I have shared above, to let our users (i.e., people who are using both Azure Key Vault, your SDK and my test double) see how they need to configure their tests when the test double is used. As a result, I must consider their reasons too and let them use the latest SDK versions when possible, so that they can benefit from all the great features and improvements you are including in these SDKs. I assume the list would contain the following items:

1. Security - Being able to use the latest SDK and relevant dependencies is a fair requirement when we are talking about a security solution like Azure Key Vault.
2. New features - As soon as your new SDK contains a new feature which people want to use, they will be keen to upgrade. I know this would generate work for me as well, but at least their build would not be broken right away, while I am working on the update.
3. Using a non-bleeding edge API version in production - According to the currently available, official REST documentation, the API version is 7.4 everywhere, so it might be a natural expectation that people might want to set it as a fixed version when configuring their clients, so that there are no surprises when the SDK is updated.

Since the test doubles are always one step behind the official API changes, whenever the new API version is released (or in the Go SDKs case being prepared) and the API version parameter changes, the test double needs to be updated to support the requests which are sent to the new API. While this is not done, the people using the SDK might need to make a choice to either use the latest SDK version to benefit from the items above, OR test their code using their existing pipeline. This is not a great trade-off to make in my opinion.

With that in mind, I have started to look for a way to override the API version similarly to the way the other official SDKs support it (.Net, Java, Python, NodeJS) and I have found this option:

https://github.com/Azure/azure-sdk-for-go/blob/main/sdk/azcore/policy/policy.go#L35-L37

As I have read the comment, I assumed, that the intention is in fact to allow overriding the version, but as soon as I have attempted it, I have received the error I mentioned in the ticket. With this, I assumed that it must be an unintended limitation or bug as only the Go SDK is behaving like this, the others allow setting it to the known service version without issues.

What do you think? Would it make sense to support the API version override considering these?

Thank you again for your efforts!

[gracewilcox]

Hi nagyesta! Sorry for the late response, we've discussed this new feature as a team and decided to add it for Key Vault. We're discussing where to fit the work in in the next semester planning.

[nagyesta]

Hi @gracewilcox , thank you! That is great news!