You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
With the deprecation of AAD Pod Identity, app developers working in Kubernetes have been migrating to Azure Workload Identity. The Azure.Identity library now supports a new WorkloadIdentityCredential as of version 1.9.0, and it would great to take advantage of it in the SQL client library.
While Authentication = Active Directory Default is already supported, which would include WorkloadIdentityCredential in versions >= 1.9.0, it would require a small change to help propagate a user-specified ClientId using the existing User Id property in connection strings, like it is done with managed identities today. Furthermore, it would be advantageous for client code to directly specify the use of Workload Identity, instead of having to wait for the other token mechanisms in the default credential to fail. Today the SQL client supports directly specifying managed identity using Authentication = Active Directory Managed Identity, and similarly other Azure libraries are special-casing workload identity as well. I made a similar change for the Microsoft.Extensions.Azure package to support workload identity specifically.
Describe the solution you'd like
I would like two things:
The specification of ClientId via User Id in the connection string for workload identity when using Authentication = Active Directory Default
A new SqlAuthenticationMethod value called ActiveDirectoryWorkloadIdentity that leverages the WorkloadIdentityCredential
While it could leverage new parameters in the connection string, I think we could also rely on environment variables to configure it by default, including AZURE_TENANT_ID, AZURE_CLIENT_ID, and AZURE_FEDERATED_TOKEN_FILE. These are the environment variables used today by the Azure.Identity library.
Describe alternatives you've considered
In my app code, I could rely on updating Azure.Identity myself to a version >= 1.9.0 and use the default credential + environment variables to leverage workload identity.
Additional context
Going forward, workload identity will be the Microsoft-recommended way to authenticate in AKS.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
With the deprecation of AAD Pod Identity, app developers working in Kubernetes have been migrating to Azure Workload Identity. The
Azure.Identity
library now supports a newWorkloadIdentityCredential
as of version1.9.0
, and it would great to take advantage of it in the SQL client library.While
Authentication = Active Directory Default
is already supported, which would includeWorkloadIdentityCredential
in versions >=1.9.0
, it would require a small change to help propagate a user-specified ClientId using the existingUser Id
property in connection strings, like it is done with managed identities today. Furthermore, it would be advantageous for client code to directly specify the use of Workload Identity, instead of having to wait for the other token mechanisms in the default credential to fail. Today the SQL client supports directly specifying managed identity usingAuthentication = Active Directory Managed Identity
, and similarly other Azure libraries are special-casing workload identity as well. I made a similar change for theMicrosoft.Extensions.Azure
package to support workload identity specifically.Describe the solution you'd like
I would like two things:
ClientId
viaUser Id
in the connection string for workload identity when usingAuthentication = Active Directory Default
SqlAuthenticationMethod
value calledActiveDirectoryWorkloadIdentity
that leverages theWorkloadIdentityCredential
AZURE_TENANT_ID
,AZURE_CLIENT_ID
, andAZURE_FEDERATED_TOKEN_FILE
. These are the environment variables used today by theAzure.Identity
library.Describe alternatives you've considered
In my app code, I could rely on updating
Azure.Identity
myself to a version >=1.9.0
and use the default credential + environment variables to leverage workload identity.Additional context
Going forward, workload identity will be the Microsoft-recommended way to authenticate in AKS.
The text was updated successfully, but these errors were encountered: