Let's put ourselves in the shoes of a Dagster add-on provider, for example, Azure.
Azure, for most of its SDKs, uses the TokenCredential protocol to authenticate clients. Implementations of this protocol are given by the azure-identity package.
So, we would expect from this add-on provider to come with a credential resource like this (simplified)
AZURE_CREDENTIAL_CONFIG = {
"credential": Field(Selector({
"managed_identity": {
"client_id": Field(StringSource, description="The user-assigned identity's client ID", is_required=False)
},
"secret": {
"tenant_id": Field(StringSource, description="ID of the service principal's tenant"),
"client_id": Field(StringSource, description="The service principal's client ID"),
"client_secret": Field(StringSource, description="One of the service principal's client secrets"),
}
}))
}
@resource(config_schema=AZURE_CREDENTIAL_CONFIG, description="Credential for Azure SDKs")
def credential(init_context: InitResourceContext) -> TokenCredential:
if "managed_identity" in init_context.resource_config["credential"]:
client_id = init_context.resource_config["credential"]["managed_identity"].get("client_id")
return ManagedIdentityCredential(client_id=client_id)
else:
tenant_id = init_context.resource_config["credential"]["secret"]["tenant_id"]
client_id = init_context.resource_config["credential"]["secret"]["client_id"]
client_secret = init_context.resource_config["credential"]["secret"]["client_secret"]
return ClientSecretCredential(tenant_id, client_id, client_secret)
That way, Azure resources can declare a dependency to the credential resource:
With the required resource key credential being set by the provider, we can't provide two different sets of credentials for key_vault_a and key_vault_b.
Ideas of implementation
A possible solution would be to give the ability to "map" required resource keys:
What's the use case?
Let's put ourselves in the shoes of a Dagster add-on provider, for example, Azure.
Azure, for most of its SDKs, uses the
TokenCredential
protocol to authenticate clients. Implementations of this protocol are given by theazure-identity
package.So, we would expect from this add-on provider to come with a
credential
resource like this (simplified)That way, Azure resources can declare a dependency to the
credential
resource:The problem arises when the user wants to use a client with different sets of credentials:
With the required resource key
credential
being set by the provider, we can't provide two different sets of credentials forkey_vault_a
andkey_vault_b
.Ideas of implementation
A possible solution would be to give the ability to "map" required resource keys:
Additional information
No response
Message from the maintainers
Impacted by this issue? Give it a 👍! We factor engagement into prioritization.