Support user-assigned managed identities in rad install kubernetes

[infbase]

Overview of feature request

Support the option of using a user-assigned managed identity for Azure provider instead of a service principal.
A --provider-azure-mi parameter may be introduced for the UAMI resource id, for instance, to be used instead of --provider-azure-client-id + --provider-azure-client-secret in these cases.

A positive side-effect of this is not having to redeploy components to the cluster when secrets rotate, for instance.

AB#6166

AB#12061

[AaronCrawfis]

Should be able to accomplish this via Helm chart in 0.12, and we can add CLI support in 0.13. We will validate and update this issue

[asilverman]

If I understand this request correctly and assuming my understanding of managed identities is up to date, the challenge to implement this generally is that the radius control plane runs as a service in the Kubernetes cluster while a user-assigned managed identity can only be assigned to an azure resource, however, the Radius control plane is not an azure resource at the moment so it cannot use managed identity.

That said, it may be possible to assign a managed identity on the AKS cluster hosting the Radius control plane, however this credential would not be exclusive to the Radius control plane but instead used by any/all pods in the cluster. I am not sure that this option however is meeting best security practices as it breaks the principle of least privilege.

Please correct me if I misunderstood the feature request details/design or if my mental model (described above) doesn't apply 😄

[AaronCrawfis]

I've written some docs on setting up a user-assigned managed identity as an Azure cloud provider: https://radapp.dev/operations/providers/#add-a-cloud-provider-to-an-aks-cluster-using-aad-pod-identity

This leverages pod-identity, which will eventually be deprecated in favor of workload identity, which has a better security model. There is a documented security shortcoming of using pod-identity with Kubenet cluster: https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity#using-kubenet-network-plugin-with-azure-active-directory-pod-managed-identities

[Reshrahim]

Needs more discussion on design and if we want to pick this up for 0.14

[Reshrahim]

@infbase - Hi Nuno. Can you let us know if the workaround to add the user-assigned managed identities via helm charts is working out for you? Any issues or concerns with that?

[ryanwaite]

@Reshrahim , do we need to keep this open?

[Reshrahim]

Can close this after checking with the customer this week if they were able to leverage workload identity support for Azure that we delivered a while back.

[AaronCrawfis]

Can close this after checking with the customer this week if they were able to leverage workload identity support for Azure that we delivered a while back.

This Issue is separate from the Azure direct-connection support we already have. It is requesting the ability to use a user-assigned managed identity for Radius' Azure cloud provider instead of needing to add an Azure service principal to UCP, which is the only Azure auth we support today. We used to support this in an older version of Radius, but we've since changed how cloud providers and UCP auth work, so we no longer officially support managed identities for Azure auth.

The Azure workload identity support we have today is for a user's containers talking to Azure resources via user-assigned managed identities and workload identity.

[willtsai]

@infbase - given the recent introduction of Workload Identities in Azure, we are working on supporting that instead of Azure Managed Identity given that we foresee Workload Identities to be the standard going forward. See #7308 for more details on Workload Identities.

Given this, do you think that the Workload Identities feature mentioned above would address your need here?

[willtsai]

closing in favor of #7308