Managed Identity and Workload Identity support in Azure Red Hat OpenShift

As organizations are looking to modernize their applications they are also looking for a more secure and easy-to-use application platform. Along with this move to modernization, there is a noticeable shift away from managing long-lived credentials in favor of short-term, limited privilege mechanisms that do not require active management. This has led to the rapid adoption of managed identities in Microsoft Azure, and our customers expect the same from their application platforms such as Azure Red Hat OpenShift (ARO) – a fully-managed turnkey application platform that allows organizations to focus on what matters most, delivering value to customers by building and deploying applications.

How does Azure Red Hat OpenShift use credentials today?

As with many Azure services, the service needs to perform legitimate operations within your Azure account. So the question arises as to how the service can obtain those credentials in order to operate in your account? Currently, Azure Red Hat OpenShift requires a service principal with contributor-level access on the virtual network and managed resource group (i.e. a resource group that contains all the cluster components like virtual machines, storage accounts, etc.) in order to operate. This will allow the creation and management of resources that a Red Hat OpenShift cluster requires, including virtual machines, load balancers, storage accounts, etc.

Though, with current advances in security and best practices, there is a better way.

What are managed/workload identities?

Managed identities in Microsoft Azure are a kind of security principle that can 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 privilege credentials in order to access other Azure services. The managed identities are used alongside a role assignment, which references a role definition that lists out permissions that are allowed to be performed. The role is then assigned to a managed identity to allow or even limit its access to Azure services. For example, with this combination of role definitions and role assignments, a managed identity could be assigned permissions that only allows read access to storage accounts. Now, if that identity tries to write to a storage account, that operation would be denied.

To learn more about managed identities in Azure please see the Microsoft documentation for “What are managed identities for Azure resources.”

Workload identities are the same in effect, except that instead of the identity corresponding to an integral component of the cluster, the 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 Microsoft documentation for “What are workload identities?”.

What benefits do managed identities bring to Azure Red Hat OpenShift?

Using managed identities over service principals have two main benefits:

1. Refined minimal set of permissions (principle of least privilege)
2. Short-lived credentials

Principle of least privilege is a security concept that states that only the minimal required permissions should be granted to an entity so that it can complete its task and nothing more. So, for example, if you have an application that only needs to read data from an Azure CosmosDB database, that is the only permission that the application should have. It should not have the capability to write or delete from CosmosDB, nor access to any other Azure service. This way, even if the application is compromised, the impact is limited.

The other benefit is that the credentials granted to the application are timebound. So, instead of having to manage the credentials and rotate them every so often, the access token granted will expire after a short while and will no longer be usable. Even if the token were to become compromised, that token’s validity is short enough to reduce the impact. In our example above, the application will request a new token whenever it needs to read from the database and the existing token is expired. If the application were compromised, the token granted would only be valid for a short period of time after it is granted.

We expect to have further announcements on availability and a preview in early 2025 for managed identities on ARO, so stay tuned.

How will managed identities be implemented in Azure Red Hat OpenShift?

Red Hat OpenShift (as of this writing) consists of a number of core Operators that perform the required tasks in order to install, run, manage, and delete a cluster. Currently, there are seven core OpenShift Operators and one Operator for the ARO service. There is also one additional identity requiring Azure permissions to enable the use of these identities. These are:

• OpenShift Image Registry Operator
• OpenShift Network Operator
• OpenShift Disk Storage Operator
• OpenShift File Storage Operator
• OpenShift Cluster Ingress Operator
• OpenShift Cloud Controller Manager
• OpenShift Machine API Operator
• Azure Red Hat OpenShift Service Operator
• Azure Red Hat OpenShift Federated Credential

In abiding with the principle of least privilege, ARO will have eight different managed identities and corresponding built-in roles that represent the permissions needed for each component of Red Hat OpenShift to perform its duties. In addition, the platform will require one additional identity to perform federated credential creation for the identities above. In this paradigm, the impact of an incident with one managed identity will only be limited to its set of permissions, and only during the short term validity of the access token. For example, if in the unlikely case that the managed identity for the Red Hat OpenShift File Storage Operator became compromised, it would not have any permissions to read/write/delete any virtual machines. This way the security posture of the clusters are significantly improved.

There will be a few options in terms of the workflow to create the cluster. In general, the first step will be to create the identities and perform the role bindings to the corresponding built-in roles. Then you would need to pass in the identities during cluster creation so that the service utilizes the correct identities for each of the cluster components. For those that want a quick way to create a managed identity cluster, there will also be an option for an “all-in-one” command where all the required identities are created on the user’s behalf and then the cluster is created using those identities.

Will ARO support identities for customer workloads?

Yes. Customers will be able to access Azure resources to make use of workload identities for their own workloads and applications. Utilizing Service Account Token Volume Projection and OIDC federation, you can enable workloads (pods) to use identities to access Azure resources securely.

Wrapping up

We have reviewed quite a few aspects in the blog, but the main point to walk away with is that using managed identities for your ARO cluster can help improve the security of your clusters by breaking up the permissions required into discrete components, which are then represented by an identity, and refining the permissions requested to grant only what is required for that component. Furthermore, instead of using long-lasting credentials (like a service principal with client secret credentials), managed identities enable the use of short-term credentials that expire after a short period of time. This also precludes the need to manage and rotate long term credentials.

We are actively working on the managed identity release and expect to have a preview available in early 2025 for managed identities on ARO. You can follow updates on our “What’s New in OpenShift” calls or the “What’s new with Azure Red Hat OpenShift?” documentation. In the meantime, learn more about Azure Red Hat OpenShift here.