Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
In this article, learn about managed identities and how to use them to control or enable access to Azure resources.
Important
Currently, this Azure Red Hat OpenShift feature is offered in preview only. Preview features are available on a self-service, opt-in basis. Previews are provided "as is" and "as available," and are excluded from the service-level agreements and limited warranty. Azure Red Hat OpenShift (ARO) previews are partially covered by customer support on a best-effort basis. These features aren't meant for production use.
What are managed identities
Managed identities are service principals of a special type, which can be used to control or enable access to Azure resources. They help reduce the risk of security breaches by eliminating the need to manually manage credentials, certificates, keys, or secrets. An application (or a service) utilizes Microsoft Entra ID authentication to request temporary, limited permission credentials in order to access other Azure services. To learn more about managed identities in Azure, see What are managed identities for Azure resources.
In Azure Red Hat OpenShift, the term workload identity is used to represent an application or workload that is running in the cluster that requires access to Azure services. For more information, see the documentation for What are workload identities?.
Managed identities and workload identities help minimize risk when securing workloads and applications by providing short-lived tokens rather than long-lived credentials such as a service principal with client secret credentials. This method provides a more secure authentication method for applications should credentials become compromised because of following factors:
- Short-term duration of the credentials.
- Refined minimal set of permissions, the principle of least privilege. The permissions are limited to only what the workload needs and only to the resources it needs to perform the task.
Understand identity role assignment architecture
Azure Red Hat OpenShift consists of core operators. Core operators are automated controllers responsible for managing an Azure Red Hat OpenShift cluster core infrastructure and ensuring its stability and operational health. An operator handles tasks like: deploy and maintain control plane components, manage cluster updates, oversee networking, and ensure essential cluster-level services are running correctly.
In an Azure Red Hat OpenShift cluster with managed identity support, core operators are assigned permissions from corresponding user-assigned managed identities. A user-assigned managed identity needs to be associated with each of the seven core Red Hat OpenShift operators, and the Azure Red Hat OpenShift service operator. The Azure Red Hat OpenShift operators are:
- OpenShift Image Registry Operator (image-registry)
- OpenShift Network Operator (cloud-network-config)
- OpenShift Disk Storage Operator (disk-csi-driver)
- OpenShift File Storage Operator (file-csi-driver)
- OpenShift Cluster Ingress Operator (ingress)
- OpenShift Cloud Controller Manager (cloud-controller-manager)
- OpenShift Machine API Operator (machine-api)
- Azure Red Hat OpenShift Service Operator (aro-operator)
The Azure Red Hat OpenShift cluster requires one more user-assigned managed identity. The additional user-assigned managed identity is used to enable the use of the eight core Azure Red Hat OpenShift operator managed identities and perform federated credential creation for all the managed identities. The additional managed identity is the Azure Red Hat OpenShift Cluster Identity (aro-cluster). For more information about Red Hat OpenShift cluster operators, see Cluster Operators reference.
The following image shows the relation between managed identities and role assignment. Numbers are assigned to the managed identities to demonstrate role assignment in image three.
Image 1 - Roles and user-assigned identities (all diagrams are illustrative only)
Built-in Azure roles for Azure Red Hat OpenShift
Specific Azure Red Hat OpenShift built-in Azure roles grant the required permissions to the supporting managed identities to enable cluster operations. These roles follow Azure's model by offering a standardized permission set for a common job function. The supporting built-in Azure roles are:
- Azure Red Hat OpenShift Cloud Controller Manager
- Azure Red Hat OpenShift Cluster Ingress Operator
- Azure Red Hat OpenShift Disk Storage Operator
- Azure Red Hat OpenShift Federated Credential
- Azure Red Hat OpenShift File Storage Operator
- Azure Red Hat OpenShift Image Registry Operator
- Azure Red Hat OpenShift Machine API Operator
- Azure Red Hat OpenShift Network Operator
- Azure Red Hat OpenShift Service Operator
For a detailed description of the built-in Azure Red Hat OpenShift roles see, Azure built-in roles.
Role assignment scope
An Azure Red Hat OpenShift deployment requires that a virtual network with at least two empty subnets (one for control plane nodes and the other for worker nodes) exist in a resource group. For the following Image 2 example, this resource group is called the Network Resource Group.
Image 2 - Network resource group
An Azure Red Hat OpenShift cluster with managed identities requires the creation of user-assigned managed identities with their corresponding role assignments. Follow the steps to Create an Azure Red Hat OpenShift cluster with managed identities enabled. After you created an Azure Red Hat OpenShift, the role assignments in the Network Resource Group will look like the following example in Image three.
Image 3 - Role assignments on network objects
The scope of the identity role assignments is performed at the most limited scope possible. Most managed identities are on the specific subnets required, while the Network Operator, which requires read permission on the virtual network, is performed at that scope.
There are three other assignments that aren't represented in Image three:
- Disk Storage and Image Registry - These assignments are performed by the installer and are only required on the managed resource group. This is the resource group created by the installer to host the service infrastructure.
- Cluster Identity - This assignment is set on the other identities themselves in order to be able to create the federated credentials for those components to operate.
The role assignment scopes are represented in the following image .
Image 4 - Role assignments
Considerations
When you use managed identities and adhere to least privilege principles, it provides many benefits. However, there are some considerations or tradeoffs to keep in mind.
Since role assignments should happen at the lowest scope possible, there are going to be more role assignments. In our case, with assignments at the subnet scope, if there are more subnets in use by the cluster like, segregating workloads into different subnets, the role assignments need to happen on those subnets as well.
Since Azure has a limit of 4,000 role assignments per subscription, if the limit is a concern, consider performing the role assignments at a higher level (such as the virtual network or resource group). Be sure to consider your security policies and the Azure inheritance hierarchy which can have you granting permissions to unintended resources. For example, performing a role assignment at the resource group would grant that identity access to every object in that resource group. For more information, see Understanding scope
Important
When you perform role assignments at higher level scopes like, virtual network or resource group, it can have you granting permissions to unintended resources.
Depending on which scope you decide to perform the role assignments at, the total number of role assignments will differ. The following are the total number of role assignments for a basic cluster install, depending on which scope is selected to perform the role assignments:
- Subnet scope: 28 (11 on network objects + 8 on managed identities + 8 on managed resource group + 1 for the resource provider)
- Virtual network scope: 23 (6 on network objects + 8 on managed identities + 8 on managed resource group + 1 for the resource provider)
- Network resource group scope: 16 (7 on network resource group + 8 on managed resource group + 1 for the resource provider) (assuming the managed identities are in the same network resource group)
- There can be more assignments on optional components/features
- +5 for each added subnet
- +4 if using bring your own (BYO) Network Security Group (NSG)
- +3 if using route table
- +2 if using NAT gateway
Since the Azure Files Container Storage Interface (CSI) driver still has a dependency on shared access keys, the default Azure File StorageClass is disabled in clusters with managed / workload identity enabled by default and is optional to turn on for your cluster. If you want to use Azure File in ARO, create your own StorageClass to use shared keys to access the backing storage. For more information, see How to configure an Azure File StorageClass.
When you update your cluster, ensure you set the
upgradeable-toannotation on the cluster's CloudCredential resource. For more information, see Update an Azure Red Hat OpenShift cluster with managed identities enabled.