crossplane-contrib / provider-azure

Crossplane Azure Provider
Apache License 2.0
93 stars 64 forks source link

RBAC Migration to Microsoft Graph API from Active Directory Graph API #236

Open jbonafide623 opened 3 years ago

jbonafide623 commented 3 years ago

What problem are you facing?

Currently Crossplane's Azure provider requires Azure Active Directory Graph API permission grants. Microsoft is ending support for Active Directory Graph API on 06/30/21 https://developer.microsoft.com/en-us/microsoft-365/blogs/end-of-support-timelines-for-azure-ad-authentication-library-adal-and-azure-ad-graph/.

They are pushing for migration to Microsoft Graph API. Currently, Azure Active Directory Graph is not a one-to-one mapping to Microsoft Graph API.

For example,

In my Azure instance, I have a Service Principal with Owner role and role grant Application.ReadWriteOwned for the Azure Active Directory Graph API. This enables me to create AKSCluster resources.

When granted Application.ReadWriteOwned role grant for Microsoft Graph API, and attempting to create AKSCluster resource, I receive an "Insufficient Privileges" error within the resource.

How could Crossplane help solve your problem?

With migration from Azure's soon-to-be unsupported Active Directory Graph API to Microsoft Graph API, consumers of Crossplane will maintain on-going support for the RBAC Azure APIs.

jbw976 commented 3 years ago

I stumbled upon this just now because of a more broad push that Azure is now doing about the retiring of Azure AD Graph. We got an automated email that says we have applications in Azure that are using Azure AD Graph. Following the steps on https://github.com/microsoft/AzureADGraphApps/issues/5#issuecomment-902897058 to find which applications, it's all the applications (servicePrincipals?) that we create using the getting started docs for Azure.

So our happy path docs result in creating Azure resources that are using this soon to be retired Azure AD Graph API. They will retire it completely in June 30 2022.

Thinking back to why we first added this requirement into provider-azure, my memory is a little hazy but it definitely has to do with AKS cluster creation. During the creation of an AKS cluster, we must create a Service Principal that the AKS cluster will use to interact with Azure APIs during its lifecycle. In order to create this Service Principal programmatically in provider-azure, the user supplied ProviderConfig that is uses needs to have access to the Azure AD Graph API.

Related provider-azure code: https://github.com/crossplane/provider-azure/blob/master/pkg/clients/compute/aks.go#L207 Azure docs: https://docs.microsoft.com/en-us/azure/aks/kubernetes-service-principal?tabs=azure-cli

It seems like we need to investigate further here and update our AKS create path to stop using the deprecated Azure AD Graph API use the new (non-deprecated) Microsoft Graph API instead. Basically what @jbonafide623 concluded when they opened this ticket, but a little more roundabout way to arrive at that conclusion 😅

Migration docs: https://docs.microsoft.com/en-us/graph/migrate-azure-ad-graph-planning-checklist?view=graph-rest-1.0

matt-mi commented 2 years ago

I encountered the same issue when creating the AKS cluster wtih a SPN which has Application.ReadWriteAll and Directory.ReadWriteAll of Microsoft Graph granted. Seems like these two permissions defined in Microsoft Graph are different from ones of Azure AD Graph, but since Azure AD graph is gonna be phased out today, could you guide how to migrate to the correct permissions of Microsoft Graph so that AKS cluster can be created successfully?