Unable to decrypt/encrypt with azkv that uses CNAME alias

[PleaseStopAsking]

I am currently using an older version of sops but started work on migrating to 3.10.2 recently but ran into an issue around my use of a CNAME alias for my Azure KeyVault endpoint.

The release of 3.11 appears to have added support for setting client options via PR #1838, but no associated documentation on how to handle this.

Failed to get the data key required to decrypt the SOPS file.

Group 0: FAILED
  https://<redacted>/keys/sops-secrets-key/<redacted>: FAILED
    - | failed to decrypt sops data key with Azure Key Vault key
      | 'https://<redacted>/keys/sops-secrets-key/<redacted>':
      | challenge resource "https://vault.azure.net" doesn't match
      | the requested domain. Set
      | DisableChallengeResourceVerification to true in your client
      | options to disable. See https://aka.ms/azsdk/blog/vault-uri
      | for more information

Recovery failed because no master key was able to decrypt the file. In
order for SOPS to recover the file, at least one key has to be successful,
but none were.

Is this new functionality not a user facing option at this time or am I simply missing something?

[felixfontein]

#1838 is a purely internal change that can't be used with the CLI. It can be used by other Go programs using SOPS as a library (which we don't officially support, except for a small decrypt package that doesn't offer this either).

[PleaseStopAsking]

Understood and thanks for the clarification.

Is there any chance of exposing this in the future to the CLI? I put all my key vaults behind CNAME's for uniformity and with the underlying changes to the azure SDK, sops is essentially unusable. I am also open to other workaround's that I may be missing.

[nshampur]

We encountered this breaking change as well, after an upgrade.

Any ETA on resolution?