Putting a multicloud architecture into practice in the banking industry

There are several reasons why banks should consider connecting their cloud environments together. An on-premise environment limits the ability for the bank to scale on demand or quickly take advantage of new infrastructure offerings from third parties. On the other hand, operating fully off-premise adds additional operational risk along with the cost to migrate services.

Regulators in many markets have also taken an interest in how banks are approaching their cloud strategy. For example, Digital Operational Resilience Act (DORA) introduced new requirements for third-party risk management. This includes additional obligations with regards to business continuity and service placement. It puts the onus on the bank to ensure continued operations if there are issues with one of their third-party providers.

We are helping our banking customers meet these challenges by providing services that can be managed in a more consistent manner across cloud environments. Red Hat Advanced Cluster Management for Kubernetes  and Red Hat Advanced Cluster Security for Kubernetes are helping them to strengthen their security posture, while also reducing the complexity and cost of cloud operations.

What are the essential components of the architecture?

The diagram below gives a high-level overview of the components that need to be incorporated into this architecture.

• Identity management
• Container registry
• Secrets management
• Observability
• Security policies and management
• Cluster management

These components are the bare minimum for a running environment and should be extended through automation and infrastructure-as-code so that environments can be reproduced from a business continuity perspective.

Figure 1: Reference architecture

Using automation to bootstrap the management cluster

The bootstrapping process itself is straightforward and can be automated using Red Hat Ansible Automation Platform. What is important to note is that the underlying infrastructure provider (cloud platform or datacenter) does not change the process. All processes assume that there is no public-facing internet connection for the environment.

The automated installation is being kicked off through an Ansible Playbook that calls the underlying infrastructure platform and deploys the first cluster. If there are any further infrastructure changes required, such as the provisioning of a load balancer, provisioning storage, etc., Ansible Automation Platform can either run the automation itself or call additional automation technologies such as HashiCorp Terraform.

For the initial cluster, Red Hat Advanced Cluster Management is deployed, which will serve as our single interface to deploy, manage and destroy clusters across the target environments.

Figure 2: The bootstrapping process

Once the management cluster is in place, the integration with identity management and secrets management tooling should happen immediately, automated with Ansible Automation Platform.

The Red Hat OpenShift GitOps tooling in combination with Red Hat Advanced Cluster Management can subsequently be used to rollout and configure any Operators, Helm charts or any other software that is required for the hub cluster. This might include additional integrations with Venafi to assist with the rotation of certificates, Prisma Cloud for platform runtime security or any other tooling that is organizationally required.

The management cluster can be configured to run highly available and also to provide disaster recovery capabilities. It doesn’t matter if this cluster is running on premise or off-premise.

How do I manage the environment once it is up and running?

Once the hub cluster is up and running, the first managed clusters can be provisioned. We are assuming that key decisions such as multi-tenant vs single-tenant clusters or choosing the type of secret management engine have been made at this point.

Fundamentally, the same architecture principles as for every environment apply to banks. The biggest differences are usually audit requirements, cluster certification and hardening.

The Red Hat Advanced Cluster Management tooling and Red Hat Advanced Cluster Security platform play a key role in achieving this. Both have been deployed in the bootstrapping section.

The configuration for each cluster (Cluster-as-Code) and its policies will be defined in Red Hat Advanced Cluster Management. This can include additional automation tooling that might be required to configure cloud environments or datacenter appliances. It is typically good practice to follow the OpenShift CIS benchmark guide for any configuration decisions that have to be made. Through the compliance operator, various profiles can be chosen out of the box, such as PCI-DSS, NIST 800–53, or the mentioned CIS benchmark.

Figure 3: Management cluster

The audit logs can be configured and aggregated in a centralized hub and forwarded to any commonly used long-term storage solution.

All operators, Helm charts, or other Kubernetes/OpenShift resources that are used on the cluster and are not user workloads should be deployed and managed through the centralized Red Hat Advanced Cluster Management hub to enable standardization, simplify the audit of cluster configurations and reduce sprawl in configurations (“Snowflake clusters”), as seen in figure 3.

The Red Hat Advanced Cluster Security solution takes this a step further and focuses on managing risk for the workloads on the cluster itself. Again, policies and configurations are configured through a central solution and then applied locally. The admission controller for example enforces that the only workloads that can be deployed are those that fulfill pre-defined rules.

Red Hat Advanced Cluster Security deals with a variety of functions, such as:

• Vulnerability management (reporting, downloadable reports, remediation)
• Supply chain security (import/export and scanning of software bills of material (SBOMs), local image scanning)
• Security policies (granular control and governance of Pod Security Context)
• Network security (governance through policies, warnings and enforcement, visualizer)

A cluster in another cloud environment becomes just another pipeline since all of the security posture, configuration and audit happens at the cluster level itself. What is left to configure is networking, automated compute provisioning and attaching preferred storage providers.

This allows your organization to fully abstract from the underlying platform at an application level.

If there is a need to cover cloud environments and datacenters that are spread far away from each other, let’s say Asia-Europe-America, there might be a concern about the latency of a single management hub. To address this, Red Hat Advanced Cluster Management offers a global hub model that allows the replication of regional hubs, speeding up management, reducing downtime and scaling beyond 1000 clusters, figure 4.

Figure 4: A Global Hub model

A connected experience out of the box

Only one question remains at this point: Do you want to manage the underlying infrastructure for the cluster and the cluster itself, or do you want to consume it like a cloud-native service?

Organizations are being asked to do more with fewer people. The result is that you have to identify what is adding value to your organization and do more of that while reducing activities that add less or no value. Managing underlying infrastructure used to be necessary to run OpenShift clusters in the cloud.

With the rollout of cloud services such as Red Hat OpenShift Service on AWS, Microsoft Azure Red Hat OpenShift, Red Hat OpenShift on IBM Cloud and OpenShift Dedicated on Google Cloud Platform, however, you can now decide if it is still worth managing the clusters yourself, or if you want to consume them as a provided service.

Figure 5: Adopting cloud services

As illustrated in Figure 5, at a high level, nothing changes. What you can see within the cloud section is that you are given a different option by adopting cloud services—while the overarching management structure remains the same.

Please note that while this reference architecture is a good starting point, we do recommend talking to your solution architect to tailor the approach for your environment.