Find client ID by tags

[johngmyers]

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

The problem is that user-assigned identities only have opaque IDs. It is an administrative burden to extract the client IDs out of the IoC system used to create them and enter them in the configuration of the Kubernetes deployment system that creates the corresponding ServiceAccounts.

In other clouds, the analogue of user-assigned identities have IDs that derive from user-assigned names, so can be named using a convention.

Describe the solution you'd like

Per the principle of "Convention over Configuration", the user-assigned identity for a ServiceAccount should be discovered using tags.

The controller would have a new --cluster-name flag telling it the name of the cluster.

If a ServiceAccount for a pod being mutated omits the azure.workload.identity/client-id annotation but has a azure.workload.identity/subscription-id annotation, then the webhook should discover the client ID by performing a IdentityListBySubscription call on the subscription and finding one which contains both of the following tags:

• A KubernetesCluster tag containing the name of the cluster.
• A k8s.io_serviceaccount tag containing the namespace and name, separated by /, of the ServiceAccount.

If the search results in zero or more than one matching user-assigned identity, then the controller should fail the mutation with an appropriate error message going into the resulting Kubernetes Event.

Describe alternatives you've considered

To support multiple clusters sharing the same user-assigned identity, the controller could also support a k8s.io_cluster_CLUSTERNAME tag containing any value, where CLUSTERNAME is the name of the cluster. Such sharing is a poor practice, so this alternative is inadvisable.

Cases where multiple ServiceAccounts need to share the same user-assigned identity usually require a wildcard namespace and/or a prefix-match on the name. It would be possible to support wildcards in the value of the k8s.io_serviceaccount tag, but federated identity credentials don't support wildcards.

An additional refinement might be to add a --subscription-id flag specifying a default subscription ID. This would presumably be the subscription of the cluster. Alternatively, the controller might discover the subscription ID of the client ID that it uses to perform searches.

Setting up permissions so that the controller can list identities in other subscriptions might end up being impractical, as it might be impractical for the controller to discover the identity it should use to be able to list identities in those other subscriptions. If so, the default subscription ID mentioned in the previous paragraph might become the only subscription ID.

Additional context

I am willing to work on an implementation.

[kristeey]

Here is an example of a how you can do the similar with a k8s controller that annotate service acocunts with the azure.workload.identity/client-id annotation based on a service account label referencing the name of your Managed Identity (workload.identity.labeler/azure-mi-client-name). The controller looks for the latter label -> annotate service account -> restarts deployment using the service account.

https://github.com/kristeey/workload-identity-labeler