What to consider when using Azure AD as IDP?
This content is authored by Red Hat experts, but has not yet been tested on every supported configuration.
Author: Ricardo Macedo Martins
May 24, 2023
In this guide, we will discuss key considerations when using Azure Active Directory (AAD) as the Identity Provider (IDP) for your ARO or ROSA cluster. Below are some helpful references:
Default Access for All Users in Azure Active Directory
Once you set up AAD as the IDP for your cluster, it’s important to note that by default, all users in your Azure Active Directory instance will have access to the cluster. They can log in using their AAD credentials through the OpenShift Web Console endpoint:
However, for security purposes, it’s recommended to restrict access and only allow specific users who are assigned to access the cluster.
Restricting Access
To implement access restrictions, follow these steps:
Log in to the Azure Portal and navigate to your AAD instance.
Under Enterprise applications, select the application created for the ARO IDP configuration.
- In the selected Enterprise application, go to Properties and switch the “Assignment required?” option to YES.
- If you attempt to log in at this point, you will receive a denial error:
Enter your username:
Enter your password:
The error message indicates that only users specifically granted access to the application are allowed:
- To allow access, go to Users and groups in the main blade, click + Add user/group, and add the desired users/groups who should have access to the ARO cluster.
Search for the desired user/group and click Select.
Verify that the user has been assigned:
- You should now be able to log in with the specified user/group to your cluster:
Enter your username:
Enter your password:
You will then be logged in:
Approval Workflow
If you receive a message like the one below, it means that your AAD has the admin consent workflow enabled:
In this case, you will need to request and wait for approval from your AAD domain admin. To request access, fill out the request form:
And wait for approval:
Self-Approval Process
If you have administrative privileges, you can self-approve the request by following these steps:
Please note that these steps are based on the official guidance from Microsoft, which is available here.
- Go to your Azure Active Directory Tenant > Enterprise Applications > Admin Consent Requests > All (Preview):
- Select the application (openshift, in this case) and click Review permissions and consent:
- A new window will open, prompting you to log in with credentials of an admin with permissions:
- Click Accept to consent to the permission:
You will then see that the request was approved:
Now you will be able to log in through the AAD option:
Enter your username:
Enter your password:
It worked!
As a best practice, we recommend removing the kubeadmin user after setting up an identity provider. You can find instructions on how to do this here .
Using the Group Sync Operator
Integrating groups from external identity providers with OpenShift, such as synchronizing groups from AAD, can be a valuable feature to enhance your system’s functionality. To accomplish this, you can leverage the usage of the Group Sync Operator .
We have published a comprehensive how-to guide that walks you through the process, accessible here . By following these instructions, you’ll be able to seamlessly synchronize AAD groups into your OpenShift environment, optimizing your workflow and streamlining access management.