[Proposal] Use System Managed Identity OR User Managed Identity for AKSCluster

[MMerzinger]

Hello everyone

What problem are you facing?

During my tests with Crossplane I figured out that the AKSCluster API implementation uses a self-managed Service Principal under the hood. This comes with the following drawbacks:

• Credential rotation (currently every 5 years)
• Requires the Service Principal that is used by Crossplane to have specific privileges on the Azure AD Graph API
• Azure AD Graph API is deprecated, this issue addresses this topic

How could Crossplane help solve your problem?

I believe that using a System Assigned Managed Identity or User Managed Identity could solve these drawbacks:

• No credential rotation - credentials are hidden under the hood of ARM
• The Service Principal that is used by Crossplane does not need to have the privileges on Azure AD Graph API to manage other Service Principals - i.e. resulting in an easier usage of the azure provider

The drawback for this approach is that a change on existing cluster is required to move to a Managed Identity.

These are my thoughts on using Crossplane to deploy AKS clusters, so this is not really a feature request, but more of a discussion.

Looking forward to hear from you!

Related issues:

• [ ] https://github.com/crossplane/provider-azure/issues/164
• [ ] https://github.com/crossplane/provider-azure/issues/322

[jbw976]

Thank you for suggesting this @MMerzinger - it's long been an annoyance that our AKS controller had to create a new service principal on the fly for the new AKS cluster to use when communicating to other Azure APIs. IIRC this was required way back when this controller was first coded, but it's great to see that there are some potential improvements here on the Azure side where this is no longer required.

This has potential to definitely improve the experience here and remove the need to have this extra permission at all. Thanks for this suggestion!

I wonder if the new provider-jet-azure already support this, maybe @ulucinar has some good insight into that?

[ulucinar]

Some further details associated with this issue are here: https://docs.microsoft.com/en-us/azure/aks/use-managed-identity

[ulucinar]

I wonder if the new provider-jet-azure already support this, maybe @ulucinar has some good insight into that?

Yes, with provider-jet-azure we support using system-assigned or user-assigned managed identities via specifying them with spec.forProvider.identity. And here's the relevant doc from Terraform registry: https://registry.terraform.io/providers/hashicorp/azurerm/2.78.0/docs/resources/kubernetes_cluster#identity (Hopefully we will have these docs become part of CRD docs with https://github.com/crossplane/crossplane/blob/99a70b193197dba4ef8c30d9e4fc6f34c154f893/design/one-pager-terrajet-metadata-extraction.md#goals :)

[ulucinar]

We had a discussion about this issue with @ezgidemirel. https://github.com/crossplane/provider-azure/pull/330 adds support for using managed identities in AKS clusters. However, using service principals is out of scope of that PR. I've opened a separate issue for it.