Oracle HYOK with CipherTrust - Using the OCI Application Load Balancer for CipherTrust High Availability

Introduction

In previous articles, we explored integrating Thales CipherTrust Manager with Oracle Cloud Infrastructure (OCI) to enable Hold Your Own Key (HYOK) capabilities, both with and without an API Gateway. While clustering CipherTrust Managers provides a level of recoverability, it does not ensure accurate high availability from a networking perspective.

The CipherTrust Manager does not natively support a virtual IP (VIP) for seamless failover between nodes.

This tutorial addresses this limitation by introducing the OCI Application Load Balancer (ALB) to provide high network availability for CipherTrust Manager instances. By placing the clustered CipherTrust Managers behind an OCI ALB, we can ensure continuous availability and fault tolerance for external key management services in OCI, even in the event of a node failure or data centre disruption.

This tutorial will walk you through the architecture, the configuration, and the considerations for deploying this setup in your OCI environment.

The steps

• [ ] STEP 01: Review the previous OCI and Thales HYOK Architectures
• [ ] STEP 02: Creating the Application Load Balancer
• [ ] STEP 03: Oracle HYOK with CipherTrust – With API Gateway and Application Load Balancer
• [ ] STEP 04: Oracle HYOK with CipherTrust – With Application Load Balancer (only)
• [ ] STEP 05: An overview of all the OCI and Thales HYOK Architectures to make the CipherTrust Manager Highly Available

STEP 01 - Review the previous OCI and Thales HYOK Architectures

Before introducing the OCI Application Load Balancer into the architecture, it's essential to revisit the existing OCI and Thales CipherTrust HYOK deployments. In earlier implementations, we covered two primary patterns:

• [HYOK with CipherTrust Manager and API Gateway]
• [HYOK with CipherTrust Manager without API Gateway]

This section will briefly summarize these two designs and highlight their strengths and limitations, setting the foundation for introducing the OCI Application Load Balancer to close the availability gap.

Both architectures relied on clustering multiple CipherTrust Managers to provide recoverability, but they lacked accurate network-level high availability due to the absence of native VIP support in CipherTrust Manager. Each deployment handled key management effectively, but introduced potential single points of failure from a network routing and service accessibility perspective.

Before you begin, make sure you have the following in place:

• [Two or more Thales CipherTrust Manager instances deployed in different Availability Domains or Fault Domains (AND CLUSTERED)].
• A VCN with appropriate subnets (private or public, depending on your architecture).
• This is where you will place the OCI Load Balancer.
• Certificates (if you're using SSL termination at the ALB).
• This is something we will explain in this tutorial.

STEP 02 - Creating the Application Load Balancer

To achieve high availability for the Thales CipherTrust Manager at the network layer, we introduce the OCI Application Load Balancer (ALB) into the architecture. The ALB will be a single, resilient access point that intelligently distributes incoming requests across the clustered CipherTrust nodes.

This step will provide an OCI Application Load Balancer that fronts multiple CipherTrust Manager instances. You will configure backend sets, health checks, SSL termination (if applicable), and listener rules tailored to your HYOK deployment—whether you're using the API Gateway or not.

This load balancer setup ensures that the key management service remains reachable even if one of the CipherTrust nodes becomes unavailable, significantly improving the reliability and fault tolerance of your external key management integration with OCI.

1. Navigate to the Load Balancers Page

• Open the OCI Console.
• Go to Networking > Load Balancers.

• Click Create Load Balancer.

• Name: Choose a descriptive name (e.g., Load_Balancer_for_CCKM).
• Type: Choose private or public, depending on your use case.
• Scroll down

• VCN and Subnet: Select the VCN and subnet(s) where the ALB will be deployed (in the right compartment).
• Click on Next.

• Policy: Weighted round robin.
• Leave the backend servers blank; we will configure these later.
• Scroll down.

• Health Check Policy: Select HTTP with port 80 for now, we will change this later.
• Scroll down.

• Backend set Name: Choose a descriptive name (e.g., CTM_Appliances).
• Click on Next.

• Listener Name: Choose a descriptive name (e.g., LISTENER).
• Listener Traffic Type and Port: TCP and port 80, we will change these later.
• Click on Next.

• Leave all the logging settings at their default.
• Click on Next.

• Review the selected settings and click on Submit.

• Notice that the Load Balancer will be created.

• When the load Balancer is created, it will be active.
• Click on Listenersto review the listener we need to edit.

• Click on Backend setsto review the Backend set that we will need to edit.
• Also, notice that the health is showing up as incomplete.
• This is because we still need to add the CTM backend servers to the set.

• We need to add a certificate before configuring the listener and the backend set (with SSL).
• Navigate to Certificates and ciphers.
• Click on Add certificate.

• Ensure you have a valid signed cert and private key created for the Load Balancer.
• In [this tutorial ], I have explained how to create a CSR and use the CTM to sign the cert with its local CA.

• Also, ensure you have the Root CA (Bundle ready).

• Certificate Name: Choose a descriptive name (e.g., LB-CTM-CERT).
• Select: Paste SSL certificate.
• Paste the (signed) SSL Certificate here.

• Select: Specify CA certificate.
• Select: Paste CA certificate.
• Paste the CA (bundle) Certificate here.

• Select: Specify Private key.
• Select: Paste Private key.
• Paste the Private Key here.
• Click on Add certificate.

• Notice that the work request is accepted.
• Click on View all work requests.

• Notice that the request has succeeded.

• Navigate to Certificates and ciphers.
• Notice that the certificate is added.

• Navigate to Backend sets.
• Click on the three dots to open the menu of the created backend set.
• Click on Edit.

• Enable SSL.
• Certificate resource: Load Balancer managed certificate
• Select the Certificate that you added earlier.
• Click on Save changes.

• Click on Close.

• Navigate to Listeners.
• Click on the three dots to open the menu of the created backend set.
• Click on Edit.

• Change the Protocol to TCP.
• Change the Port to 443.
• Enable SSL.
• Certificate resource: Load Balancer managed certificate
• Select the Certificate that you added earlier.
• Click on Save changes.- Enable SSL.
• Certificate resource: Load Balancer managed certificate
• Select the Certificate that you added earlier.
• Click on Save changes.

• Click on Close.

• Notice that the listener is now listening on TCP port 443.

• Navigate to Backend sets.
• Notice that the health is still incomplete.
• This is because we have not added any servers as a backend to the set.

• Click on the three dots to open the menu of the created backend set.
• Click on Update health check.

• Change the Protocol to TCP.
• Change the Port to 443.
• Click on Save changes.

• Click on Close.

• Click on the backend set you created earlier.

• Click on Backends.
• Click on Add backends.

• Backend Type: IP addresses.
• Add the following backends (IP addresses of the CTMs):
• CTM 1 (AMS)
• IP address: 10.111.10.32
• Port: 443
• Weight: 1
• CTM 2 (ASH)
• IP address: 10.222.10.111
• Port: 443
• Weight: 2
• Click on Add.

• Notice that the health will show up as Critical.
• Performing the health check on the CTM servers might take a minute.

• Notice that the health is now changed to OK.
• Navigate back to the Backend set overview.

• Notice that the overall health of the backend set is also OK here.
• Navigate back to the Load Balancer overview.

• Notice that the Load balancer is active, the overall health is OK, and the load balancer has an IP address.

Make sure you create a DNS record for the load balancer. I have created an A record in the Private DNS Listener inside the OCI VCN.

STEP 03 - Oracle HYOK with CipherTrust – With API Gateway and Application Load Balancer

In this step, we integrate the ALB into your existing API Gateway–based HYOK deployment, ensuring a seamless and highly available architecture.

In this architecture, we combine the strengths of the OCI API Gateway and the OCI Application Load Balancer (ALB) to enhance the reliability and security of the Oracle HYOK integration with Thales CipherTrust Manager.

The API Gateway continues to serve as the secure public-facing entry point, enforcing authentication, authorization, and routing policies. Behind it, the Application Load Balancer distributes requests across multiple CipherTrust Manager nodes, ensuring high availability and fault tolerance at the network layer.

This layered design maintains a secure access model through the API Gateway. It addresses the lack of native VIP support in CipherTrust Manager by introducing a resilient backend through the ALB.

• Navigate to the API Gateway created in this tutorial: 'HYOK with CipherTrust Manager and API Gateway

• Click on Deployments.
• Click on the Deployment.

• Click on Edit.

Click on Routes.

• Notice that the URL points to the ctm1.oci-thales.lab FQDN, which is the AMS CTM.

• Change the URL to now point to lb-ctm.oci-thales.lab FQDN, the ALB we just created.
• Click on Next and make sure to save the changes.

The following illustration shows the end-to-end traffic flow with the OCI API Gateway and the OCI ALB integrated into the architecture.

STEP 04 - Oracle HYOK with CipherTrust – With Application Load Balancer only

In this step, you'll learn how to configure and use the OCI ALB as the sole access point for CipherTrust Manager in an Oracle HYOK deployment, enabling a clean, performant, and highly available architecture.

In this architecture, we simplify the deployment by removing the API Gateway and placing the OCI Application Load Balancer (ALB) directly in front of the Thales CipherTrust Manager cluster. This approach is ideal for private integrations where public access is not required and the goal is to ensure high availability within a secure, internal network.

By routing requests through the ALB, we can distribute traffic across multiple CipherTrust nodes while maintaining session resilience and failover capabilities, even in the event of a node or availability domain failure. This setup addresses the key limitation of the CipherTrust Manager's lack of native VIP support, without the additional complexity of API Gateway policies and authentication flows.

Follow the steps in the [HYOK with CipherTrust Manager without API Gateway] tutorial. But now, all the (AMS) CTM1 IP addresses have been changed to the LB IP address.

• The (OCI) Integrated Applications Resource app.
• The CTM1 External Vault Endpoint URL Hostname.
• This change will also be synced to the (ASH) CTM2 when the CTM is in a cluster.
• The OCI Private Endpoint (the OCI External Ley Management Service will use that.)

This is the detailed integration flow for the OCI with Thales Integration (HYOK) with only the LB in the path.

The following illustration shows the end-to-end traffic flow with only the OCI ALB integrated into the architecture.

STEP 05 - An overview of all the OCI and Thales HYOK Architectures to make the CipherTrust Manager Highly Available

There is no one-size-fits-all approach to deploying Thales CipherTrust Manager (CTM) for Hold Your Own Key (HYOK) in Oracle Cloud Infrastructure (OCI). Multiple architectural options are available to achieve a resilient, highly available deployment depending on your network topology, security requirements, and available infrastructure, whether cloud-based or on-premises.

This section provides a consolidated overview of all supported architecture patterns for integrating CTM with OCI HYOK, focusing on high availability. These include combinations of:

• Single or dual data center deployments
• Use of the OCI API Gateway
• Use of the OCI Application Load Balancer (ALB)
• Use of on-premises or data center–hosted load balancers, both with and without high availability

Each architecture has benefits and trade-offs regarding complexity, failover capabilities, and control. Whether you're running a fully cloud-native setup, operating across hybrid environments, or leveraging legacy load balancers in your data centers, there is a model that fits.

The architectures covered include:

Architecture #	Description
1	CTM in a single data center – basic setup without API Gateway or Load Balancer
2	CTM in a single data center with OCI API Gateway – external access, no HA
3	CTMs in two data centers with OCI API Gateway and OCI ALB – full HA solution
4	CTMs in two data centers with OCI API Gateway and on-prem load balancer (no HA) – partial resilience
5	CTMs in two data centers with OCI API Gateway and on-prem load balancer (HA) – HA managed externally
6	CTM in one data center with OCI API Gateway and on-prem load balancer (no HA) – limited failover
7	CTMs in two data centers with OCI ALB only – internal access, full network-level HA without API Gateway

This overview will help you compare and select the architecture that best aligns with your technical and operational requirements.

(1) The following illustration shows the end-to-end traffic flow with no OCI API Gateway and no load balancing integrated into the architecture.

(2) The following illustration shows the end-to-end traffic flow with only the OCI API Gateway and no load balancing integrated into the architecture.

(3) The following illustration shows the end-to-end traffic flow with the OCI API Gateway and the OCI ALB integrated into the architecture.

(4, 5 and 6) The following illustration shows the end-to-end traffic flow with the OCI API Gateway and the on-prem load balancers integrated into the architecture.

(7) The following illustration shows the end-to-end traffic flow with only the OCI ALB integrated into the architecture.

Conclusion

Ensuring high availability for Thales CipherTrust Manager in an Oracle Cloud Infrastructure (OCI) HYOK deployment is essential for maintaining secure, uninterrupted access to customer-managed encryption keys. While clustering CipherTrust Managers provides recoverability, it is insufficient to meet high availability requirements at the network level.

This article demonstrated how the OCI Application Load Balancer can close that gap, either in conjunction with the OCI API Gateway or as a standalone solution for internal access. We also reviewed several real-world architecture patterns, including hybrid models that leverage on-premises load balancers, helping you choose the design that aligns with your infrastructure strategy and availability goals.

By thoughtfully integrating OCI's networking services with Thales CipherTrust, organizations can build a resilient and secure external key management solution that supports enterprise-grade compliance and operational continuity.