wombatu-kun commented on PR #16541: URL: https://github.com/apache/iceberg/pull/16541#issuecomment-4539052008
@nandorKollar good catch — yes, the same `DefaultAzureCredential` fallback exists on the ADLS path. That ADLS exposure is actually called out in #16465 itself: the report notes the Key Vault case "is less exposed than the ADLS location issue because it is config-driven rather than metadata-driven, but it is still an endpoint-trust break." So the ADLS case is known as a separate concern and considered the more exposed of the two — there the target storage host comes from table-metadata locations rather than a single catalog config property. I kept this PR scoped to Key Vault on purpose, because the ADLS mitigation can't be the same shape. For Key Vault, requiring a catalog-vended credential is reasonable since ambient Key Vault auth is a niche setup. For ADLS, authenticating to your own storage via a managed identity (`DefaultAzureCredential`) is a mainstream, documented production configuration, so simply removing the ambient fallback would be a significant breaking change. The ADLS case more likely needs a different mitigation (e.g. validating/allow-listing the storage host a bearer token is sent to), which deserves its own design discussion rather than being folded into this PR. Since #16465 came in through the private Apache security list, I'd suggest the ADLS location case be triaged the same way rather than expanded here. But let's land this Key Vault PR first, and I'm happy to help drive the ADLS follow-up afterwards. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
