Enable OCI HYOK with Thales CipherTrust Manager Using OCI Load Balancer for High Availability
Introduction
In the previous tutorial, we explored integrating Thales CipherTrust Manager with Oracle Cloud Infrastructure (OCI) to enable Hold Your Own Key (HYOK) capabilities, both with and without an OCI API Gateway. While clustering CipherTrust Managers provides a level of recoverability, it does not ensure accurate high availability from a networking perspective.
The Thales CipherTrust Manager does not natively support a virtual IP address (VIP address) for seamless failover between nodes.
This tutorial addresses the limitation by introducing OCI Load Balancer to provide high network availability for Thales CipherTrust Manager instances. By placing the clustered CipherTrust Managers behind an OCI Load Balancer, 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, configuration, and considerations for deploying this setup in your OCI environment.
Objectives
- Task 1: Review existing OCI and Thales CipherTrust Manager HYOK architectures.
- Task 2: Create an OCI Load Balancer.
- Task 3: Integrate OCI Load Balancer with an existing OCI API Gateway-based HYOK deployment.
- Task 4: Integrate OCI Load Balancer with an existing HYOK deployment without OCI API Gateway.
- Task 5: Review all the OCI and Thales CipherTrust Manager HYOK architectures to make the Thales CipherTrust Manager highly available.
Task 1: Review the Existing OCI and Thales CipherTrust Manager HYOK Architectures
Before introducing OCI Load Balancer into the architecture, it is essential to revisit the existing OCI and Thales CipherTrust Manager HYOK deployments. In earlier implementations, we covered two primary patterns:
-
Set up an OCI Hold Your Own Key using Thales CipherTrust Manager with OCI API Gateway
-
Set up an OCI Hold Your Own Key using Thales CipherTrust Manager without OCI API Gateway
This section will briefly summarize these two designs and highlight their strengths and limitations, setting the foundation for introducing the OCI Load Balancer to close the availability gap.
Both architectures relied on clustering multiple Thales CipherTrust Managers to provide recoverability, but they lacked accurate network-level high availability due to the absence of native VIP address support in Thales 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). For more information, see Set Up Two Thales CipherTrust Cloud Key Manager Appliances in OCI, Create a Cluster between them, and Configure One as a Certificate Authority.
-
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 are using SSL termination at the OCI Load Balancer). This is something we will explain in this tutorial.
Task 2: Create an OCI Load Balancer
To achieve high availability for the Thales CipherTrust Manager at the network layer, we introduce OCI Load Balancer into the architecture. The OCI Load Balancer will be a single, resilient access point that intelligently distributes incoming requests across the clustered Thales CipherTrust Manager nodes.
This task will provide an OCI Load Balancer that fronts multiple Thales CipherTrust Manager instances. You will configure backend sets, health checks, SSL termination (if applicable), and listener rules tailored to your HYOK deployment whether you are using the OCI API Gateway or not.
This OCI Load Balancer setup ensures that the key management service remains reachable even if one of the Thales CipherTrust Manager nodes becomes unavailable, significantly improving the reliability and fault tolerance of your external key management integration with OCI.
-
Log in to the OCI Console, navigate to Networking and click Load Balancers.
-
Click Create Load Balancer.
-
Enter the following information.
- Name: Enter a descriptive name (for example,
Load_Balancer_for_CCKM
). - Type: Select private or public, depending on your use case.
- VCN and Subnet: Select the VCN and subnet(s) where the OCI Load Balancer will be deployed in the right compartment.
- Click Next.
- Policy: Select Weighted round robin.
- Leave the Select backend servers blank, we will configure these later.
- Health Check Policy: Select HTTP with port
80
for now, we will change this later.
- Backend set Name: Enter a descriptive name (for example,
CTM_Appliances
). - Click Next.
- Listener Name: Enter a descriptive name (for example,
LISTENER
). - Listener Traffic Type and Port: TCP and port
80
, we will change these later. - Click Next.
- Leave all the logging settings at their default.
- Click Next.
- Name: Enter a descriptive name (for example,
-
Review the information and click Submit.
-
Note that the OCI Load Balancer will be created. After a few minutes, it will show Active.
-
Click Listeners to review the listener we need to edit.
-
Click Backend sets to review the backend set that we will need to edit. Also, note that the health is showing up as Incomplete. This is because we still need to add the Thales CipherTrust Manager backend servers to the set.
-
We need to add a certificate before configuring the listener and the backend set with SSL. To add, navigate to Certificates and ciphers and click Add certificate.
-
Ensure you have a valid signed certificate and private key created for the OCI Load Balancer.
To create a Certificate Signing Request (CSR) and use the Thales CipherTrust Manager to sign the certificate with its local CA, see Create a CSR for both Thales CCKM Appliances and Sign by the CA.
-
Also, ensure you have the root CA (bundle ready).
-
In Add certificate, enter the following information.
- Certificate name: Enter a descriptive name (for example,
LB-CTM-CERT
). - Select Paste SSL certificate.
- SSL certificate: Paste the signed SSL certificate.
- Select Specify CA certificate.
- Select Paste CA certificate.
- CA certificate: Paste the CA (bundle) certificate.
- Select Specify Private key.
- Select Paste Private key.
- Private key: Paste the private key.
- Click Add certificate.
- Certificate name: Enter a descriptive name (for example,
-
Note that the Work request submitted is accepted and click View all work requests.
-
Note that the request has succeeded.
-
Navigate to Certificates and ciphers and note that the certificate is added.
-
Navigate to Backend sets, click the three dots to open the menu of the created backend set and then click Edit.
-
In Edit backend set, enter the following information.
- Select Use SSL to enable SSL.
- Certificate resource: Select Load balancer managed certificate.
- Select the certificate name.
- Click Save changes.
-
Click Close.
-
Navigate to Listeners, click the three dots to open the menu of the created backend set and then click Edit.
-
In Edit listener, enter the following information:
- Protocol: Select TCP.
- Port: Select 443.
- Select Use SSL.
- Certificate resource: Select Load balancer managed certificate.
- Select Certificate name.
- Click Save changes.
-
Click Close.
-
Note that the listener is now listening on TCP port
443
. -
Navigate to Backend sets and note that the health is still incomplete. This is because we have not added any servers as a backend to the set.
-
Click the three dots to open the menu of the created backend set and then click Update health check.
-
In Update health check, enter the following information.
- Protocol: Select TCP.
- Port: Select 443.
- Click Save changes.
-
Click Close.
-
Click the backend set you created earlier.
-
Click Backends and then click Add backends.
-
In Add backend, enter the following information.
- Backend Type: Select IP addresses.
- Add the following backends (IP addresses of the CTMs):
- CTM 1 (AMS)
- IP address: Enter
10.111.10.32
. - Port: Select 443.
- Weight: Select 1.
- IP address: Enter
- CTM 2 (ASH)
- IP address: Enter
10.222.10.111
. - Port: Select 443.
- Weight: Select 2.
- IP address: Enter
- CTM 1 (AMS)
- Click Add.
-
Note that the health will show up as Critical. Performing the health check on the Thales CipherTrust Manager servers might take a minute.
-
Note that the health is now changed to OK. Now, navigate back to the Backend set overview.
-
Note that the overall health of the backend set is also OK. Now, navigate back to the OCI Load Balancer overview.
-
Note that the OCI 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. We have created an A record in the private DNS listener inside the OCI VCN.
Task 3: Integrate OCI Load Balancer to an Existing OCI API Gateway–based HYOK Deployment
In this task, we will integrate the OCI Load Balancer into your existing OCI 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 Load Balancer to enhance the reliability and security of the OCI HYOK integration with Thales CipherTrust Manager.
The OCI API Gateway continues to serve as the secure public-facing entry point, enforcing authentication, authorization, and routing policies. Behind it, the OCI 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 OCI API Gateway. It addresses the lack of native VIP address support in Thales CipherTrust Manager by introducing a resilient backend through the OCI Load Balancer.
-
Navigate to the OCI API Gateway created in the following tutorial: Set up an OCI Hold Your Own Key using Thales CipherTrust Manager with OCI API Gateway.
-
Navigate to Deployments and click Deployment.
-
Click Edit.
-
Click Routes.
-
Note 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 OCI Load Balancer we just created and click 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 Load Balancer integrated into the architecture.
Task 4: Integrate OCI Load Balancer to an Existing but without OCI API Gateway-based HYOK Deployment
In this task, you will learn how to configure and use the OCI Load Balancer as the sole access point for Thales CipherTrust Manager in an OCI HYOK deployment, enabling a clean, performant, and highly available architecture.
In this architecture, we simplify the deployment by removing the OCI API Gateway and placing the OCI Load Balancer 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 OCI Load Balancer, we can distribute traffic across multiple Thales CipherTrust Manager 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 Thales CipherTrust Manager’s lack of native VIP address support, without the additional complexity of OCI API Gateway policies and authentication flows.
Follow the tasks listed in the following tutorial: Set up an OCI Hold Your Own Key using Thales CipherTrust Manager without OCI API Gateway. But now, all the (AMS) CTM1 IP addresses have been changed to the load balancer IP address.
- The OCI Integration 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 Key Management Service will use that).
This is the detailed integration flow for OCI with Thales CipherTrust Manager integration (HYOK) with only the OCI Load Balancer in the path.
The following illustration shows the end-to-end traffic flow with only the OCI Load Balancer integrated into the architecture.
Task 5: Review all the OCI and Thales CipherTrust Manager HYOK Architectures to make the Thales CipherTrust Manager Highly Available
There is no one-size-fits-all approach to deploying Thales CipherTrust Manager for Hold Your Own Key (HYOK) in 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 Thales CipherTrust Manager 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 Load Balancer.
- 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 are 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 OCI API Gateway or OCI 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 Load Balancer – full HA solution |
4 | CTMs in two data centers with OCI API Gateway and on-premises load balancer (no HA) – partial resilience |
5 | CTMs in two data centers with OCI API Gateway and on-premises load balancer (HA) – HA managed externally |
6 | CTM in one data center with OCI API Gateway and on-premises load balancer (no HA) – limited failover |
7 | CTMs in two data centers with OCI Load Balancer only – internal access, full network-level HA without OCI API Gateway |
This overview will help you compare and select the architecture that best aligns with your technical and operational requirements.
-
Architecture 1: The following illustration shows the end-to-end traffic flow with no OCI API Gateway and no load balancing integrated into the architecture.
-
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.
-
Architecture 3: The following illustration shows the end-to-end traffic flow with the OCI API Gateway and the OCI Load Balancer integrated into the architecture.
-
Architecture 4, 5 and 6: The following illustration shows the end-to-end traffic flow with the OCI API Gateway and the on-premises load balancers integrated into the architecture.
-
Architecture 7: The following illustration shows the end-to-end traffic flow with only the OCI Load Balancer 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 tutorial demonstrated how the OCI 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 Manager, organizations can build a resilient and secure external key management solution that supports enterprise-grade compliance and operational continuity.
Acknowledgments
- Author - Iwan Hoogendoorn (Cloud Networking Black Belt)
More Learning Resources
Explore other labs on docs.oracle.com/learn or access more free learning content on the Oracle Learning YouTube channel. Additionally, visit education.oracle.com/learning-explorer to become an Oracle Learning Explorer.
For product documentation, visit Oracle Help Center.
Enable OCI HYOK with Thales CipherTrust Manager Using OCI Load Balancer for High Availability
G40041-01
Copyright ©2025, Oracle and/or its affiliates.