Red Hat OpenShift is the platform of choice for many companies that have decided to modernize application development by adopting a cloud-native approach that makes the most of microservice and serverless patterns. This approach brings in a dramatic reduction in the time developers need to create applications, making teams much more responsive and flexible whenever they need to change applications or include new features.

OpenShift also provides multiple layers of security to the entire container lifecycle. Starting at the build phase from the image registry through deployment and runtime, OpenShift helps improve the security posture of both the applications running in a container and the infrastructure of the container itself.

OpenShift can also be deployed on-premise or on any type of cloud, and this hybrid cloud agility is a strong advantage since it gives organizations flexibility in where they run their workloads.

Microsoft Azure Red Hat OpenShift

There are many benefits in using OpenShift, being one of them the change of mindset that leads to the adoption of DevOps and DevSecOps methodologies, as shared by more and more developers every day.

The tasks involved in operating and making sure OpenShift is up to date and compliant can be daunting, however, and require very specialized engineers. OpenShift is also a resource-intensive platform and can need significant infrastructure to deliver its full potential. 

Organizations that are lacking either these required skills or infrastructure can still take full advantage of OpenShift by using Microsoft Azure Red Hat OpenShift. This version of OpenShift has the same features as the on-premise version, but is jointly managed by Red Hat and Microsoft so users don't have to worry about update cycles and maintenance. Organizations using this service can also precisely track their expenditure on the Azure portal, benefit from forecasting and be able to set a maximum budget for consumption.

How to deploy Azure Red Hat OpenShift

It is recommended to deploy Azure Red Hat OpenShift following the recommendations in the Azure Red Hat OpenShift landing zone accelerator (the code for it is in this GithHub repo). Microsoft has created landing zone accelerators to facilitate and accelerate the creation of Azure environments tailored to the workloads that they will host.

From a network perspective, the traffic that goes to the Azure Red Hat OpenShift cluster (ingress traffic) as well as the traffic that goes out of it (egress traffic) must be controlled and have security policies enforced. If you want to have a private cluster, one of the options for the former is to use the Azure Front Door service (which is specifically for Azure Red Hat OpenShift) and combine it with Azure Private Link.

In this way, the applications running on the cluster will be exposed to users that have access to the Azure Front Door subnet. These applications run behind the Azure Standard Load Balancer. Apart from this, Azure Red Hat OpenShift has a built-in ingress controller and routes that provide advanced HTTP routing, improved security and a single endpoint for all the applications in the cluster.

Figure 1. Ingress traffic to an Azure Red Hat OpenShift cluster

Figure 1. Ingress traffic to an Azure Red Hat OpenShift cluster

In Figure 1 we can see that users will utilize Azure Front Door’s IP address to send a request for the application they want to consume. This service will use Azure Private Link to get to the internal load balancer and, from there, to the requested application in the cluster.

The pods in the cluster will need access to other Azure services, some of which are also represented in Figure 1. In order to build the images for the containers, they will need a registry, such as the Azure Container Registry. It is strongly recommended that Azure Active Directory is integrated with an organization's identity provider to add another layer of security, and to use Azure Key Vault secrets to manage cluster secrets. To round this up, the cluster can also be connected to Azure Arc-enabled Kubernetes to better protect certificates, secrets and connection strings and to monitor the cluster. Alternatively, you can use Red Hat Advanced Cluster Security for Kubernetes.

There should be a subnet of private endpoints for communication between the Azure Red Hat OpenShift cluster and the rest of the Azure services. It is also advised that you use Azure Private Link for the connection to the Azure Container Registry.

Figure 2. Egress traffic from an Azure Red Hat OpenShift cluster and connection to the cluster

Figure 2. Egress traffic from an Azure Red Hat OpenShift cluster and connection to the cluster

It is recommended that the traffic that goes from the Azure Red Hat OpenShift cluster to the internet (egress traffic) go through Azure Firewall. Figure 2 also shows the recommended way for users to access the cluster itself (not the applications running on it) by connecting to a virtual machine (VM) deployed using the Azure Bastion service.

Summary

If you want to make the most of Red Hat OpenShift on scalable infrastructure without having to deal with your own management or maintenance, Azure Red Hat OpenShift is a great option. Following the recommendations in the Azure Red Hat OpenShift landing zone accelerator will help you get started with this robust and flexible enterprise Kubernetes platform for developing and running cloud-native applications.

If you are interested in more solutions built with these and other products of the Red Hat's portfolio visit the Portfolio Architecture website.

Learn more


About the author

Ricardo Garcia Cavero joined Red Hat in October 2019 as a Senior Architect focused on SAP. In this role, he developed solutions with Red Hat's portfolio to help customers in their SAP journey. Cavero now works for as a Principal Portfolio Architect for the Portfolio Architecture team. 

Read full bio