Objective

Deploying On-Prem Cloud Platform (OPCP) at your site requires gathering a set of configuration items beforehand. Some are mandatory for the initial bootstrap and cannot be changed after installation; others are optional or can be adjusted later. Preparing this list upfront is the main condition for a fast deployment with no back-and-forth.

The aim of this guide is to present, for each prerequisite, what it is used for, how to express it, and whether it is mandatory or optional.

It is intended for both architects preparing the delivery and administrators who want to understand what was configured on their platform.

Requirements

• Having read the OPCP - Network integration and platform connectivity guide, which describes the network architecture in which these prerequisites take place.
• Knowing the OPCP subscription model you have chosen (Self-managed or Fully managed by OVHcloud).
• Having an identified OVHcloud point of contact for the delivery, to whom you will transmit the gathered items.

Instructions

1. How to read this guide

For each prerequisite, you will find:

• a description explaining its role on the platform,
• whether it is mandatory or optional,
• whether it can be modified after installation,
• the associated network flows when the prerequisite implies a communication between OPCP and a service in your environment,
• a generic example to help you express the expected value.

2. OVHcloud interconnection (managed mode only)

If you have subscribed to the Fully managed by OVHcloud offering, an IPsec tunnel must be established between your site and OVHcloud to enable remote operations and support. You must provide:

• the public IP address of your IPsec endpoint,
• the subnet you expose on your side (typically the OPCP administration subnet),
• the agreed pre-shared key (PSK) for authentication, transmitted through a secure channel.

The default cryptographic parameters are IKEv2 + PSK + AES-256 + SHA-256 + DH group 14 + PFS. If your security policy requires different parameters, discuss this with your OVHcloud point of contact before deployment.

In Self-managed mode, this prerequisite does not apply.

3. Administration network

Definition of the management network on which OPCP will be positioned. You must provide:

• the subnet allocated to OPCP (for example: 172.30.1.0/24),
• the default gateway address (for example: 172.30.1.254).

This network will host the OPCP controllers and their VIP. It is also the starting point for the outbound flows toward your internal services (NTP, DNS, syslog, S3, LDAP).

4. OPCP environment variables

OPCP uses several variables to uniquely identify the deployment. They appear in Netbox, in the logs, in the monitoring, and in several other components. You must provide a value for each of them:

5. OPCP controller names and addresses

For each OPCP Core Controller in your deployment, provide:

• the hostname (FQDN or short name depending on your convention),
• the IP address on the administration network.

In a 3-controller configuration, also provide the VIP (Virtual IP) shared between the three nodes, which will be the single entry point to the OpenStack APIs and Horizon.

Example in a 3-controller configuration:

6. Certificates

OPCP must present valid TLS certificates for its interfaces (OpenStack API, Horizon, internal services). Three options are supported; you must choose one of them before deployment.

Option A — Recommended - Intermediate certificate authority provided by the customer

You provide an intermediate CA derived from your internal PKI. OPCP uses it to sign the service certificates. You must transmit:

• the intermediate CA certificate,
• the associated private key (transmitted through a secure channel agreed with your OVHcloud point of contact).

The rotation of certificates issued under this intermediate remains handled by CertManager on the OPCP side.

Option B — Self-signed certificate authority generated by OPCP

OPCP generates its own internal certificate authority and signs the required certificates. You do not need to provide anything. Rotation is handled automatically by CertManager.

This is the simplest option, suitable if your security policy accepts a CA internal to the OPCP perimeter. You will however need to distribute OPCP's root certificate to your clients in order to avoid security warnings.

Option C — Let's Encrypt

OPCP requests certificates automatically from Let's Encrypt. This option requires:

• a compatible validation method (HTTP-01 or DNS-01) reachable from OPCP,
• the associated prerequisites for this method (public resolution of the domain, outbound access to ACME servers, and so on).

Specify with your OVHcloud point of contact the method you have chosen and the configurations to put in place on your side.

7. NTP — Time synchronisation

OPCP needs a reliable time source for the correct operation of all of its components (log consistency, certificate validity, quorum election, and so on). Provide:

• one or more IP addresses of NTP servers, or DNS names if DNS resolution is configured.

Example:

• 172.30.1.200 / ntp1.example.com
• 172.30.1.201 / ntp2.example.com

Plan for opening the UDP/123 flow from the OPCP administration network to your NTP servers.

8. DNS — Domain delegation to OPCP

OPCP exposes its interfaces through FQDNs under a domain that you delegate to it. You must provide:

• the domain name allocated to this OPCP platform (for example: opcp01.example.com).

On the DNS infrastructure side, you must create a forwarder from your internal resolvers to the OPCP VIP, so that any request for *.opcp01.example.com is resolved by OPCP.

9. DNS resolvers — External resolution

If OPCP needs to resolve external domain names (for example the FQDN of your S3 endpoint or your LDAP directory), provide the address of one or more DNS resolvers.

Example:

• 172.30.1.100
• 172.30.1.101

This prerequisite is only needed if you enable integrations relying on external FQDNs (S3 backup, long-term metrics, LDAP federation, and so on). For a strictly air-gapped platform configured by IP, it can be omitted.

10. Syslog — Log centralisation

OPCP can forward its logs to a centralised syslog infrastructure for long-term retention and analysis. Provide:

• the IP address or FQDN of the syslog server (for example: 172.30.1.250),
• the listening port,
• the protocol: TCP or UDP.

11. Backup — S3 endpoint

OPCP can back up the infrastructure state (configurations, control plane state, metadata) to an S3-compatible endpoint that you provide. You must transmit:

• the S3 endpoint (for example: s3.example.com:443),
• the Access Key,
• the Secret Key,
• the bucket name dedicated to backups (for example: opcp01-backup-dc1),
• the S3 region name (for example: paris).

The access keys must be transmitted through a secure channel agreed with your OVHcloud point of contact.

12. Long-term metrics storage — S3 endpoint

OPCP continuously collects metrics on the platform. To retain them beyond the local retention window, you can offload them to an S3 bucket. The elements to provide are the same as for the backup, but the bucket must be separate:

• S3 endpoint,
• Access Key,
• Secret Key,
• bucket name dedicated to metrics (for example: opcp01-metrics-dc1),
• region name.

You can reuse the same endpoint and the same S3 credentials as for the backup, provided you use a different bucket.

13. LDAP — Identity federation

OPCP integrates Keycloak as an identity provider. If you wish to federate access with your corporate directory (Active Directory or another LDAP server), provide:

• the IP addresses or FQDNs of your LDAP servers (for example: ldap.example.com, 10.3.0.5, 10.3.0.6),
• the listening port (typically 636 for LDAPS).

Without federation, users are managed directly in the Keycloak embedded in OPCP.

14. SSH public key

To access the OPCP controllers after the initial bootstrap (in particular to use opcp-cli and opcp-diag), provide one or more SSH public keys of the customer-side administrators.

In Fully managed by OVHcloud mode, this key gives the customer access to the administration tools in addition to the access of the OVHcloud teams.

Summary

Pay particular attention to the prerequisites not modifiable after installation: they will shape your platform for the long term.

Go further

• OPCP - Network integration and platform connectivity
• Getting started with your OPCP

For training or technical assistance implementing our solutions, contact your sales representative or visit our Professional Services page to request a quote and have your project analyzed by our experts.

Join our community of users.

¹: S3 is a trademark of Amazon Technologies, Inc. OVHcloud's service is not sponsored by, endorsed by, or otherwise affiliated with Amazon Technologies, Inc.