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
Intro:
Azure AD workload identity federation is a new capability. It applies to both application identities and managed identities in Azure AD. The k8s team has built additional components around this that help customers use this capability in their k8s deployments. It's essential for the Azure Identity SDK to support this pattern so customers can easily benefit from this capability.
Allow customers to seamlessly move their code, which uses DefaultAzureCredential, to also run in a k8s cluster.
Do this in a way that isn't confusing to customers. They could either use application identities or managed identities. Telling a customer to pass a managed identity when they're using an application identity is going to be very confusing.
Provide predictability on the credential. For example, a customer may want to exclude ManagedIdentityCredential, so they know the request isn't going through the compute endpoint like IMDS.
Proposal:
Add a new credential type named WorkloadIdentityCredential. This new credential type will become part of the DefaultAzureCredential auth flow.
The WorkloadIdentityCredential will come into play if the necessary environment variables are populated: (AZURE_FEDERATED_TOKEN_FILE, AZURE_CLIENT_ID, AZURE_TENANT_ID). These are set up by the k8s platform based on the assertions on a service account.
Allow an optional client ID parameter to be passed into DefaultAzureCredential, which can be used by the customers to override the AZURE_CLIENT_ID in the event they have more than one identity for which they intend to use this flow.
With these changes, customers can do the following:
Use DefaultAzureCredential as their main guidance to their developers.
Recommend excluding the necessary credential types to get predictability in their code execution.
Pass explicit client IDs for which they want to get an Azure AD token.
Ideally with these changes, we'd also remove the current implementation where ManagedIdentityCredential is overloaded to work with these env. Doing this is ideal to avoid the ensuing confusion for customers.
The text was updated successfully, but these errors were encountered:
Related to #15615.
Intro:
Azure AD workload identity federation is a new capability. It applies to both application identities and managed identities in Azure AD. The k8s team has built additional components around this that help customers use this capability in their k8s deployments. It's essential for the Azure Identity SDK to support this pattern so customers can easily benefit from this capability.
DefaultAzureCredential
, to also run in a k8s cluster.ManagedIdentityCredential
, so they know the request isn't going through the compute endpoint like IMDS.Proposal:
Add a new credential type named
WorkloadIdentityCredential
. This new credential type will become part of theDefaultAzureCredential
auth flow.The
WorkloadIdentityCredential
will come into play if the necessary environment variables are populated: (AZURE_FEDERATED_TOKEN_FILE
,AZURE_CLIENT_ID
,AZURE_TENANT_ID
). These are set up by the k8s platform based on the assertions on a service account.Allow an optional client ID parameter to be passed into
DefaultAzureCredential
, which can be used by the customers to override theAZURE_CLIENT_ID
in the event they have more than one identity for which they intend to use this flow.With these changes, customers can do the following:
DefaultAzureCredential
as their main guidance to their developers.Ideally with these changes, we'd also remove the current implementation where
ManagedIdentityCredential
is overloaded to work with these env. Doing this is ideal to avoid the ensuing confusion for customers.The text was updated successfully, but these errors were encountered: