Azure: Require catalog-provided credentials for Key Vault client#16541
Open
wombatu-kun wants to merge 1 commit into
Open
Azure: Require catalog-provided credentials for Key Vault client#16541wombatu-kun wants to merge 1 commit into
wombatu-kun wants to merge 1 commit into
Conversation
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #16465.
Summary
AzureKeyManagementClientbuilt its Key VaultKeyClientfrom an arbitraryazure.keyvault.urland authenticated using ambient Azure credentials — when noadls.token-credential-providerwas configured, the credential chain fell back toDefaultAzureCredentialBuilder().build()(managed identity / environment / Azure CLI). A malicious or mis-scoped catalog configuration could therefore redirect Key Vault authentication traffic to an attacker-controlled endpoint and exfiltrate the client's ambient bearer token, as reported in #16465.Following the direction suggested on the issue, the Key Vault client now authenticates only with a credential supplied through configuration (a catalog-vended
adls.token, or an explicitly configuredadls.token-credential-provider) and no longer silently falls back to ambientDefaultAzureCredential. When no such credential is provided it fails fast with aValidationException. With this change a malicious catalog can at most recover a credential it already issued, rather than the client's ambient identity.What changed
AzurePropertiesgainskeyVaultTokenCredential(), which returns the catalog-/operator-supplied credential and is empty when only ambient credentials would be available; the inlineTokenCredentialbuilder previously used for ADLS is extracted into a shared helper and reused.AzureKeyManagementClientnow resolves its credential through this method and throws aValidationExceptionwhen none is configured. ADLS storage credential behavior is unchanged — this is a Key Vault–only change.Note: the supplied token must be scoped for Key Vault (for the public cloud,
https://vault.azure.net).adls.tokenis reused as the carrier rather than introducing a new property; a dedicatedazure.keyvault.tokencould be added as a follow-up if preferred.Tests
TestAzurePropertiesadds unit coverage forkeyVaultTokenCredential(): resolution fromadls.token, resolution from a custom token-credential provider, and — critically — that it is empty (no ambient fallback) when nothing is configured. The integrationTestAzureKeyManagementClientnow asserts both sides of the new contract against a live vault: the old URL-only configuration fails withValidationException, and wrap/unwrap works when a Key Vault-scoped token is provided viaadls.token.