Managed Identity and Workload Identity on Azure Red Hat OpenShift in public preview

With modernizing applications being top of mind for many organizations, it is also important to consider how underlying platforms and technologies are addressing security along the way. Customers are looking for ways to minimize risk and be able to secure applications with a shift towards short-lived, limited privilege methods that will limit impact if an application is compromised.

We are pleased to announce that support for managed identity and workload identity is now in public preview on Microsoft Azure Red Hat OpenShift (ARO). As a fully managed, comprehensive application platform, Azure Red Hat OpenShift automates the deployment and management of clusters, so organizations can focus on building and deploying applications, not managing infrastructure. 

More secure authentication

Managed identities and workload identities can 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 can provide a more secure authentication method for applications if credentials were to be compromised because of 2 main factors:

1. Short-term duration of the credentials.
2. Refined minimal set of permissions (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. 

Reduced operational burden

Users can also simplify operational management without the need to manually manage secrets, certificates, keys and credentials or perform rotations for long-term credentials. Additionally, each core cluster component has its own assigned managed identity and minimally scoped permissions, simplifying management of credentials and allowing for more granular access control. 

Understanding identity role assignment architecture

Azure Red Hat OpenShift consists of a number of operators that are responsible for managing an Azure Red Hat OpenShift cluster’s infrastructure and ensuring its stability and operational health. An operator handles tasks like deploying and maintaining control plane components, managing cluster updates, overseeing networking and ensuring essential cluster-level services are running correctly.

In an Azure Red Hat OpenShift cluster with managed identity support, these operators are assigned permissions from corresponding user-assigned managed identities. A user-assigned managed identity will need to be associated with each of the 7 core Red Hat OpenShift operators and the Azure Red Hat OpenShift service operator. These 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)

An additional user-assigned managed identity will be required by the Azure Red Hat OpenShift cluster to enable the use of the above operators’ managed identities and perform federated credential creation for all the managed identities. This is the Azure Red Hat OpenShift Cluster Identity (aro-cluster).

Image 1. Roles and user assigned managed identities

To understand identity role assignment architecture, we’ll use conceptual illustrations. 

First, start with a resource group that contains our network objects. This is called the network resource group. It will contain the vNet and at least 2 empty subnets, one for the control plane nodes and the other for the worker nodes. These could be newly created or existing.

Image 2. Network resource group

The numbers in image 1 are meant to make the role assignment illustration a bit simpler. As you can see, each identity has a corresponding built-in role. After creating the managed identities and performing the role assignments with the corresponding built-in roles at the proper scopes, it would look like the image below.

Image 3. Role assignments on network objects

From this illustration, you can see the scope of the identities is limited to the resources that the service needs to operate on. There is one assignment, the Network Operator, which does require read access on the vNet. You’ll also notice that there are 3 other assignments that are not represented in the above image. Two of these, Disk Storage operator and the Cluster Image Registry operator, are only required on the managed resource group (which is the resource group created by Azure Red Hat OpenShift to host the service’s infrastructure) and is performed by the service.  While one, Cluster Identity, is actually set on the other identities themselves in order to be able to create the federated credentials for those components to operate. Putting it all together, it looks like the following:

Image 4. Role assignments

How to create a cluster with managed identities

At a conceptual level, the process for creating a cluster would entail:

1. Creating a resource group for your networking resources (vNet, subnets and the Azure Red Hat OpenShift cluster resource) or using an existing;
2. Creating the vNet (or using an existing);
3. Creating the subnets for the control plane nodes and for the worker nodes;
4. Creating the required user-assigned managed identities;
5. Performing the correct role assignments;
6. Creating the cluster and passing in the created identities.  

Steps 1-3 are the same as they are currently for Azure Red Hat OpenShift clusters. In effect, the main difference is the creation of the user-assigned managed identities, performing the correct role assignments, and passing those into the create command.

Create the user-assigned managed identities

The entire process is detailed in the documentation. Although this blog article will not review the entire process, it’s beneficial to discuss key aspects. You’ll need to create 9 user-assigned managed identities, as described above. Let’s take a look at the process, using one operator/identity as an example. 

Using the CLI, creation of the identity can look like the following:

az identity create --resource-group <RESOURCEGROUP> --name machine-api

Perform the role assignment

Next, you’ll create the role assignment. There are built-in roles to be assigned for each identity and they have to be assigned on the correct resource. 

Continuing our example above with the machine API operator, performing the role assignment can look like the following:

az role assignment create \
  --assignee-object-id "<MACHINE_API_ID_OBJECT_ID>" \
  --role "/subscriptions/$SUBSCRIPTION_ID/providers/Microsoft.Authorization/roleDefinitions/0358943c-7e01-48ba-8889-02cc51d78637" \
  --scope "/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$RESOURCEGROUP/providers/Microsoft.Network/virtualNetworks/aro-vnet/subnets/master"
  
az role assignment create \
  --assignee-object-id "<MACHINE_API_ID_OBJECT_ID>" \
  --role "/subscriptions/$SUBSCRIPTION_ID/providers/Microsoft.Authorization/roleDefinitions/0358943c-7e01-48ba-8889-02cc51d78637" \
  --scope "/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$RESOURCEGROUP/providers/Microsoft.Network/virtualNetworks/aro-vnet/subnets/worker"

Notice that we are performing 2 role assignments, one on each of the subnets. This ensures that this identity can only perform the listed permissions in the role, only on the assigned subnets of our cluster. If there are other subnets, those are not affected and the managed identity cannot operate on those. 

If the number of role assignments are a concern, you may also assign the scope at a higher level resource like the vNet or even resource group, but be aware of security considerations and the Azure inheritance hierarchy which may 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. See Understanding scope for more information.

Create the cluster

After performing all the corresponding role assignments, you’ll create the cluster. The create command makes use of 3 new parameters. 

• One is --enable-managed-identity that tells the service you want a managed identity cluster.
• The second is --assign-cluster-identity <cluster-id> which tells the resource provider which user-assigned managed identity is the cluster identity.
• The third is --assign-platform-workload-identity <key> <value> which takes in a key-value pair. The first argument, the key, tells the resource provider the OpenShift operator you are targeting. The second argument, the value, is the name of the identity created to be used for the OpenShift operator represented by the key. 

Let’s take a look at an example. If we are going to pass in the values for the machine API operator, and we created a user-assigned managed identity called “machine-api” as per our example, then this parameter will look like the following:

--assign-platform-workload-identity machine-api machine-api

The names of the user-assigned managed identities can be anything you choose (when you create them), although it is recommended to make it something meaningful.  The key, however, should not be modified.

A full create command may look like the following:

az aro create \
  --resource-group <RESOURCEGROUP> \
  --name <CLUSTER_NAME> \
  --vnet aro-vnet \
  --master-subnet master \
  --worker-subnet worker \
  --version <VERSION> \
  --enable-managed-identity \
  --assign-cluster-identity aro-cluster \
  --assign-platform-workload-identity file-csi-driver file-csi-driver \
  --assign-platform-workload-identity cloud-controller-manager cloud-controller-manager \
  --assign-platform-workload-identity ingress ingress \
  --assign-platform-workload-identity image-registry image-registry \
  --assign-platform-workload-identity machine-api machine-api \
  --assign-platform-workload-identity cloud-network-config cloud-network-config \
  --assign-platform-workload-identity aro-operator aro-operator \
  --assign-platform-workload-identity disk-csi-driver disk-csi-driver

That's it! Now grab a coffee and a snack while your cluster is being created.

Using workload identities for your own applications

Workload identities are supported for your own applications. As per the Microsoft Azure documentation for What are workload identities? “[a] workload identity is an identity you assign to a software workload (such as an application, service, script or container) to authenticate and access other services and resources.” In our case, you can use a user-assigned managed identity for your applications to access other Azure services.  

The process will entail:

1. Obtaining the OpenID Connect (OIDC) issuer URL;
2. Creating a user-assigned managed identity for your application;
3. Performing the role assignment on the desired resource;
4. Creating a Kubernetes service account;
5. Setting the annotation on the service account;
6. Creating the federated credential;
7. Deploy the application ensuring that:
   1. The .spec.serviceAccountName is set
   2. The label azure.workload.identity/use: "true" is set

Clean up

To delete your cluster, you’ll still use the same delete command, as illustrated in the image below.

az aro delete -n $CLUSTER_NAME -g $RESOURCEGROUP

This will delete all the cluster components and federated credentials. However, you must remember to delete user-assigned managed identities and role assignments yourself.

We are currently working towards a general release of managed identities for Microsoft Azure Red Hat OpenShift with future enhancements. For updates on the latest Azure Red Hat OpenShift releases or to learn more, check out: 

• Understanding Azure Red Hat OpenShift with managed identities documentation
• Microsoft Tech Community blog for the latest Azure Red Hat OpenShift updates
• “What's new with Azure Red Hat OpenShift?” documentation
• Azure Red Hat OpenShift