Body: <p>I'm in the process of migrating our aks and the application from <a href="https://github.com/Azure/aad-pod-identity" rel="nofollow noreferrer">aad-pod-identity</a> to the new <a href="https://azure.github.io/azure-workload-identity/docs/" rel="nofollow noreferrer">workload-identity</a>. And I've hit a roadblock.</p>
  <p>In the current setup, I use this <a href="https://github.com/Azure/aad-pod-identity/tree/master/charts/aad-pod-identity" rel="nofollow noreferrer">helm chart</a> to install aad-pod-identity.
  By default, the option &quot;forceNamespaced&quot; is set to false. This is exactly what we needed because we deploy our applications with <a href="https://argoproj.github.io/cd/" rel="nofollow noreferrer">argocd</a>, which deploys helm charts. These are different versions of our application. For example, pull request deployments or public preview versions.</p>
  <p>The important part is, all pods in all deployments of the application use the same &quot;aadpodidbinding&quot; label to the same AzureIdentityBinding CRD of AadPodIdentity.</p>
  <p>The problem now is, I can't figure out how I should configure WorkloadIdentity to give me the same functionality.
  It requires using Kubernetes ServiceAccounts in Combination with something called <a href="https://learn.microsoft.com/en-us/azure/aks/learn/tutorial-kubernetes-workload-identity#establish-federated-identity-credential" rel="nofollow noreferrer">Azure Federated Identity Credentials</a>.</p>
  <p>But ServiceAccounts only work in their namespace, right?
  So I would need one for each namespace (which are ever changing).
  But for it to be authorized to exchange its token for a token in azure, it needs to be linked with an Azure Federated Identity Credential.</p>
  <p>This doesn't work with our setup, because at this point we only deploy helm charts to an existing Kubernetes setup and can't just easily go back and create more Azure resources to bind to, if that deployment creates a new Namespace with a new ServiceAccount.</p>
  <p>Maybe our application helm chart could include a job that uses the azure-cli...
  But then again, what credentials to use... That part should be done in Terraform, which already creates the Azure Managed Identity itself.</p>
  <p>What I tried to find out so far, but found no answers to, is:</p>
  <ol>
  <li>Is it possible to use a ServiceAccount in another namespace on a pod?</li>
  <li>Is it possible to bind the Federated Identity Credentials to a Kubernetes Role instead, which the ServiceAccounts (in each namespace) could then use?</li>
  </ol>
  <p>Would be great If someone has an answer to those.</p>
  <p>Otherwise, I have to wait for his <a href="https://github.com/Azure/azure-workload-identity/issues/373" rel="nofollow noreferrer">Github Issue</a> I just discovered.
  This would solve my problem because I could just create one Federated Identity Credential per AKS and let all ServiceAccounts match with the same one (basically 1:N)</p>
  
Comments: CC BY-SA 4.0
Comments: 2023-11-25T21:28:43.650Z
Comments: https://learn.microsoft.com/en-us/azure/aks/workload-identity-overview states this
  "Many-to-one where multiple service accounts references the same Microsoft Entra object." which seems to address your question 2.
Comments: mloskot
Comments: CC BY-SA 4.0
Comments: 2024-01-22T20:23:40.730Z
Comments: Been a while, but iirc the problem with that was, although the service accounts (many) can point to the same (one) identity in azure, if their sub claim - which is system:serviceaccount:<account-name> - is not registered in that managed identity as a federated credential, azure denies the token exchange. Also, another limitation is you can only have 20 of those on the same managed identity.
  
  Well, all of that is being discussed in that issue I discovered just after posting the original question, and no one there from MS mentioned any workaround... So I guess there is none.
Comments: floge07
Tags: <kubernetes><azure><azure-kubernetes-service>
Title: Using AKS WorkloadIdentity with a "shared" ServiceAccount?
UserDisplayName: floge07
ThreadText: # Using AKS WorkloadIdentity with a "shared" ServiceAccount?
  
  (Asked by: username_0 on 2023-06-26)
  
  I'm in the process of migrating our aks and the application from [aad-pod-identity](https://github.com/Azure/aad-pod-identity) to the new [workload-identity](https://azure.github.io/azure-workload-identity/docs/). And I've hit a roadblock.
  
  In the current setup, I use this [helm chart](https://github.com/Azure/aad-pod-identity/tree/master/charts/aad-pod-identity) to install aad-pod-identity.
  By default, the option "forceNamespaced" is set to false. This is exactly what we needed because we deploy our applications with [argocd](https://argoproj.github.io/cd/), which deploys helm charts. These are different versions of our application. For example, pull request deployments or public preview versions.
  
  The important part is, all pods in all deployments of the application use the same "aadpodidbinding" label to the same AzureIdentityBinding CRD of AadPodIdentity.
  
  The problem now is, I can't figure out how I should configure WorkloadIdentity to give me the same functionality.
  It requires using Kubernetes ServiceAccounts in Combination with something called [Azure Federated Identity Credentials](https://learn.microsoft.com/en-us/azure/aks/learn/tutorial-kubernetes-workload-identity#establish-federated-identity-credential).
  
  But ServiceAccounts only work in their namespace, right?
  So I would need one for each namespace (which are ever changing).
  But for it to be authorized to exchange its token for a token in azure, it needs to be linked with an Azure Federated Identity Credential.
  
  This doesn't work with our setup, because at this point we only deploy helm charts to an existing Kubernetes setup and can't just easily go back and create more Azure resources to bind to, if that deployment creates a new Namespace with a new ServiceAccount.
  
  Maybe our application helm chart could include a job that uses the azure-cli...
  But then again, what credentials to use... That part should be done in Terraform, which already creates the Azure Managed Identity itself.
  
  What I tried to find out so far, but found no answers to, is:
  
  1. Is it possible to use a ServiceAccount in another namespace on a pod?
  2. Is it possible to bind the Federated Identity Credentials to a Kubernetes Role instead, which the ServiceAccounts (in each namespace) could then use?
  
  Would be great If someone has an answer to those.
  
  Otherwise, I have to wait for his [Github Issue](https://github.com/Azure/azure-workload-identity/issues/373) I just discovered.
  This would solve my problem because I could just create one Federated Identity Credential per AKS and let all ServiceAccounts match with the same one (basically 1:N)
  
  **Tags:** kubernetes, azure, azure-kubernetes-service
  
  > **Comments:**
  > **username_1**: https://learn.microsoft.com/en-us/azure/aks/workload-identity-overview states this "Many-to-one where multiple service accounts references the same Microsoft Entra object." which seems to address your question 2.  
  > **username_0**: Been a while, but iirc the problem with that was, although the service accounts (many) can point to the same (one) identity in azure, if their sub claim - which is system:serviceaccount:<account-name> - is not registered in that managed identity as a federated credential, azure denies the token exchange. Also, another limitation is you can only have 20 of those on the same managed identity.  Well, all of that is being discussed in that issue I discovered just after posting the original question, and no one there from MS mentioned any workaround... So I guess there is none.  
  
  ---
  
  ## 0 answers
  
  