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.
This is a feature request to support many:1 serviceAccounts in Kubernetes to Azure AD service principals. The use case is to have different serviceAccounts in Kubernetes being able to use the same identity in Azure.
Describe the solution you'd like
Ability to configure workload identity in such a way that multiple serviceAccounts map to a single service principal.
Describe alternatives you've considered
Having 1:1 serviceAccount to service principal. This works only to a certain scale. There's a limit on roleAssignments in Azure, and for applications with many serviceAccounts that needs to share the same Azure access; consolidating to less service principals in Azure works best to avoid this limit.
The text was updated successfully, but these errors were encountered:
The support for configuring wildcards in Federated Identity Credentials is an AAD feature that's not available today. There is already another issue requesting the same feature that has more context: #373. Please feel free to add to that issue.
Is your feature request related to a problem? Please describe.
This is a feature request to support many:1 serviceAccounts in Kubernetes to Azure AD service principals. The use case is to have different serviceAccounts in Kubernetes being able to use the same identity in Azure.
Describe the solution you'd like
Ability to configure workload identity in such a way that multiple serviceAccounts map to a single service principal.
Describe alternatives you've considered
Having 1:1 serviceAccount to service principal. This works only to a certain scale. There's a limit on roleAssignments in Azure, and for applications with many serviceAccounts that needs to share the same Azure access; consolidating to less service principals in Azure works best to avoid this limit.
The text was updated successfully, but these errors were encountered: