Repository navigation
Azure: add support to specify token credential provider - #14136
Conversation
|
@kevinjqliu As of now, I have avoided including the |
| TokenCredential credential(); | ||
|
|
||
| /** | ||
| * Initialize Azure credential factory from catalog properties. |
There was a problem hiding this comment.
instead of "factory" this should probably just say "Initialize the credential provider..."
| * | ||
| * @param properties catalog properties | ||
| */ | ||
| void initialize(Map<String, String> properties); |
There was a problem hiding this comment.
similar to AWS we should probably only pass down properties that have a specific prefix, such as adls.token-credential-provider., so only adls.token-credential-provider.client_id would be passed to the credential provider but not any other catalog properties
| import com.azure.core.credential.TokenCredential; | ||
| import java.util.Map; | ||
|
|
||
| public interface AzureTokenCredentialProvider { |
There was a problem hiding this comment.
| public interface AzureTokenCredentialProvider { | |
| public interface AdlsTokenCredentialProvider { |
There was a problem hiding this comment.
Reasoning is same as below - applicable for any azure services
| import org.apache.iceberg.relocated.com.google.common.base.Strings; | ||
| import org.apache.iceberg.util.PropertyUtil; | ||
|
|
||
| public class AzureTokenCredentialProviders { |
There was a problem hiding this comment.
| public class AzureTokenCredentialProviders { | |
| public class AdlsTokenCredentialProviders { |
There was a problem hiding this comment.
TokenCredential is applicable for all Azure services, so should we keep the Azure has prefix or Adls - considering we only support Adlsv2
Also, if renamed should we move the classes under adlsv2 package?
There was a problem hiding this comment.
no need to move this to a different package but we should still rename the class to Adls... because the property also says adls....
There was a problem hiding this comment.
renamed the classes
| public void testDefaultFactory() { | ||
| AzureTokenCredentialProvider provider = AzureTokenCredentialProviders.defaultFactory(); | ||
| assertThat(provider).isNotNull(); | ||
| assertThat(provider) |
There was a problem hiding this comment.
you can combine both assertions and have assertThat(provider).isNotNull().isInstanceOf(..)
| public class TestAzureTokenCredentialProviders { | ||
|
|
||
| @Test | ||
| public void testDefaultFactory() { |
There was a problem hiding this comment.
we don't really need the test prefix in all of those new test methods. Instead just use meaningful method names, such as useDefaultFactory() or emptyPropertiesWithNoProvider() and so on
|
|
||
| assertThat(provider).isNotNull(); | ||
| assertThat(provider).isInstanceOf(DummyTokenCredentialProvider.class); | ||
| assertThat(provider.credential()).isInstanceOf(DummyTokenCredential.class); |
There was a problem hiding this comment.
I think we should also update TestAzureProperties to make sure the credential actually comes back correctly and has the right value
56e46e5 to
f4b18d4
Compare
|
@nastra I have incorporated the most of the suggestions. |
| * <p>Example: adls.token-credential-provider=com.example.MyCustomTokenCredentialProvider | ||
| * | ||
| * <p>When set, the {@link AdlsTokenCredentialProviders#from(Map)} method will use this provider | ||
| * to get Azure credentials instead of using the default. |
There was a problem hiding this comment.
| * to get Azure credentials instead of using the default. | |
| * to get ADLS credentials instead of using the default. |
| public static final String ADLS_TOKEN = "adls.token"; | ||
|
|
||
| /** | ||
| * Configure the Azure token credential provider used to get {@link TokenCredential}. A fully |
There was a problem hiding this comment.
| * Configure the Azure token credential provider used to get {@link TokenCredential}. A fully | |
| * Configure the ADLS token credential provider used to get {@link TokenCredential}. A fully |
There was a problem hiding this comment.
I'd prefer Azure here since the token credentials are from Azure Identity. Plus we're adding support for OneLake as well as ADLS.
| @Test | ||
| public void emptyPropertiesWithNoProvider() { | ||
| Map<String, String> properties = ImmutableMap.of(); | ||
| AdlsTokenCredentialProvider provider = AdlsTokenCredentialProviders.from(properties); |
There was a problem hiding this comment.
nit: the provider can be inlined in all of the tests: assertThat(AdlsTokenCredentialProviders.from(properties))...
| } | ||
| } | ||
|
|
||
| // Dummy TokenCredential for testing |
There was a problem hiding this comment.
comment can be removed as I think it's obvious from the naming of the class
| assertThat(provider.credential()).isInstanceOf(DummyTokenCredential.class); | ||
| } | ||
|
|
||
| // Dummy implementation for testing |
| } | ||
|
|
||
| static class DummyTokenCredentialProvider implements AdlsTokenCredentialProvider { | ||
| static Map<String, String> lastInitializedProperties; |
There was a problem hiding this comment.
why not just call this properties?
| verify(clientBuilder, never()).credential(any(StorageSharedKeyCredential.class)); | ||
| } | ||
|
|
||
| // Helper classes for custom provider testing |
nastra
left a comment
There was a problem hiding this comment.
left a few more comments but overall LGTM
There was a problem hiding this comment.
Thank you for the contribution! This is a lot cleaner than implementing individual auth method (like in #13829). Perhaps we can also refactor the static token auth (#13825) as a follow up.
Regarding the naming convention, ADLS vs Azure, I would prefer to use Azure since these are Azure identity auth methods.
We're also adding support for this on the Microsoft OneLake side. "Azure" would be less confusing than ADLS since OneLake is ADLS-compatible
Since everything else mentions ADLS (except AzureProperties), i think it would be less confusing to users if we just default everything to ADLS for now.
We can look to rename ADLS -> Azure in the future
| public static final String ADLS_TOKEN = "adls.token"; | ||
|
|
||
| /** | ||
| * Configure the Azure token credential provider used to get {@link TokenCredential}. A fully |
There was a problem hiding this comment.
I'd prefer Azure here since the token credentials are from Azure Identity. Plus we're adding support for OneLake as well as ADLS.
|
Thanks @kevinjqliu @nastra for the review. I have addressed the last set of review suggestions. Please have a look |
Similar to AWS,
adls.token-credential-providercan be used to specify theTokenCredentialprovider.This is useful where user can configure custom token credential or in-built TokenCredential impl like
ClientSecretCredential- where specifying clientId,secret not possible via env variables like federation.In built-one support auto-refresh of access-token on the expiry.