Annotate ServiceAccounts with the managed identity by name

[dghubble]

Is your feature request related to a problem? Please describe.

Is is plausible to allow Kubernetes Service Accounts to be annotated with the name of a managed identity (predictable), rather than it's client_id (not predictable)?

kind: ServiceAccount
metadata:
  annotations:
   azure.workload.identity/client-id: "a1b2c3..."

Describe the solution you'd like

Generating a bunch of service accounts, it can be cumbersome to plumb around the client_id values Azure chooses. Compared with being able to set a predictable value and having the mutating admission controller do the querying.

kind: ServiceAccount
metadata:
  annotations:
   azure.workload.identity/managed-identity: "my-identity"

In AWS EKS, with OpenID Connect, service accounts are annotated with the name of an AWS role that can be assumed. Using a predictable value is quite valuable. There is no need to create a role, wait for some role id, and then annotate service accounts with an id.

kind: ServiceAccount
metadata:
  annotations:
  eks.amazonaws.com/role-arn: arn:aws:iam::111122223333:role/my-role      

Describe alternatives you've considered

Additional context

[aglees]

I'm wondering if it's worth the time to create a workaround for this.

One possible solution would be to have a mutating webhook, powered by a pod that has been workload identified to read from a given subscription (or wider scope), do the mapping of resource-id to client-id for ServiceAccount resources.

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    azure.workload.identity/resource-id: /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ManagedIdentity/userAssignedIdentities/{userAssignedIdentityName}
...

to

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    azure.workload.identity/resource-id: /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ManagedIdentity/userAssignedIdentities/{userAssignedIdentityName}
    azure.workload.identity/client-id: {clientId}
...

There'd still be a need to bootstrap this deployment on the cluster with Workload Identity, along with pre-creating a user assigned identity that do the mapping.

Thoughts?

I guess there'd be a multitude of considerations such as how to handle when the resource-id now maps to a new user-assigned identity, and that might lend itself to being more of a controller.

[wenzel-felix]

In the last weeks, I have started working on a "ClientId Syncer" to avoid even having to manually add any annotations to the service accounts for Azure Workload Identity in the cluster. This may be interesting in this case. https://github.com/shiftavenue/azure-clientid-syncer

[kristeey]

This feature would be very much appreciated in a GitOps setup where Managed Identities and Federated credentials are created as part of the application manifests it self.

[dghubble]

I think even just being able to specify the managed identity by resource id would be "good enough", as these are predictable. It doesn't require waiting for the workload identity to be created and assigned a client id.

kind: ServiceAccount
metadata:
  annotations:
   azure.workload.identity/managed-identity-resource-id: "/subscriptions/SUB/resourceGroups/GROUP/providers/Microsoft.ManagedIdentity/userAssignedIdentities/NAME"

[sonnyhcl]

Can we just support similar thing inside ManagedIdentityCredential does to support resourceId? I know this needs joint effort for AAD, azure-identity, and azure-workload-identity projects. But it should be a good start point from azure-workload-identity since the scenario is here