# Network planning Network planning for Ripple Custody involves configuring secure communication between platform components, managing external traffic through corporate proxies, and provisioning Transport Layer Security (TLS) certificates for all endpoints. This guide covers firewall rules, proxy configuration, and public key infrastructure (PKI) requirements. ## Internal firewall rules (Core to Secure) This section specifies the "Core to Secure" communication requirements — the communication between the *core platform components* (running on OpenShift/Kubernetes) and the *secure components* (the notary and the vault). In many on-premises deployments, the secure components are isolated on specialized, high-security infrastructure. Examples include IBM Hyper Protect Virtual Servers (HPVSs) on IBM LinuxONE, which exist on a separate network from the application cluster. You must update all necessary firewall rules to allow this critical inter-component communication. ### Communication direction and purpose The *core platform components* (e.g., API Gateway, Ledger Accounting Service) expose themselves via Ingress endpoints, which typically remain internal to the Kubernetes cluster. The *secure components* initiate the primary communication flow by polling the core platform for work. This model requires inbound firewall rules. Allow polling activity *into* the Core cluster from the isolated network hosting the notary and vault. ### Specific endpoint requirements To support this communication, the core platform exposes a dedicated internal endpoint: * Endpoint: notary-bridge. * This endpoint is for internal platform use only and is the target for all communication from the secure components. * Notary: The notary communicates with the core platform via a dedicated gRPC stream to this endpoint. * Vault: The vault component regularly polls the API Gateway via an HTTPS GET request to this endpoint. ### Security mechanism You must secure all connections between the core platform components and the secure components. * TLS: At a minimum, we recommend standard TLS (Server Authentication) for these internal dependencies. * mTLS (Recommended): For the most secure, zero-trust communication model, we strongly recommend mTLS (mutual authentication). Both the client (notary/vault) and the server (the core platform) cryptographically verify each other's identity before exchanging information. * Application Layer Trust: The notary and vault use mutual trust at the application layer to exchange information securely and mitigate the risk of a man-in-the-middle attack. ### Additional internal requirement (image pull) The firewalled environment hosting the secure components (e.g., the Hyper Protect Virtual Server) must also have network rules that allow it to pull container images. Grant outbound access to either: * The official Ripple Custody registry: metaco.azurecr.io * An internal, client-hosted container repository where you have mirrored the images. ## External traffic via forward proxy It is a common enterprise requirement for all outbound internet-facing traffic to traverse a corporate HTTP/HTTPS forward proxy. This allows security monitoring and control. Platform components require external access for several key functions. This guide explains how to configure the platform components to successfully connect to external endpoints, such as Ripple-hosted services or public blockchain nodes, through your existing network infrastructure. ### Configuration The platform's Helm charts provide standard parameters (e.g., HTTPS_PROXY, NO_PROXY) to configure proxy settings. * HTTPS_PROXY: You must set this variable to point to your corporate forward proxy (e.g., https_proxy: http://proxy.mybank.com:8080). * NO_PROXY: This is a critical setting to prevent internal traffic from being routed to the external proxy. This list must include: * Your internal cluster domain (e.g., .cluster.local) * Your OpenShift/Kubernetes API server * All internal service FQDNs * The subnets for your internal networks (e.g., pod and service networks) This configuration ensures that components like Indexers can connect to external blockchain nodes. All internal traffic (e.g., component-to-database, component-to-component) remains within the cluster. ## Ingress and TLS certificate configuration This section details the *public key infrastructure* (PKI) requirements for the platform. You must secure all communication, both external (user-facing) and internal (component-to-component), with TLS. You are responsible for providing the necessary TLS assets from your internal Certificate Authority (CA) or a trusted public CA. ### Certificate requirements You must generate and configure the necessary TLS assets for all ingress endpoints. This typically includes a server certificate and its corresponding private key. * Wildcard certificate (recommended): The simplest approach is to use a wildcard certificate for your cluster's domain (e.g., *.apps.my-openshift.com). * Individual certificates: If a wildcard is not an option, you must generate individual certificates for each externally-facing endpoint. ### Ingress endpoints You must secure the following ingress endpoints with TLS certificates: * api.: The main API Gateway for client applications. * frontend.: The optional Web UI. * openid.: The OpenID authentication server endpoint. * notary-bridge.: The internal endpoint for secure component communication. The installation guide provides instructions for generating and applying these TLS assets (including your CA certificate, the server certificate, and the server certificate key). Store them as Kubernetes TLS secrets that the Ingress controller uses. ## Checklist: Before you proceed ### Decisions made - [ ] **Core to Secure communication**: TLS or mTLS selected. - [ ] **Forward proxy**: Corporate proxy required for external traffic (yes/no). - [ ] **Certificate strategy**: Wildcard certificate OR individual certificates per endpoint. ### Artifacts ready **Internal firewall (Core to Secure components)** - [ ] Firewall rule: notary to `notary-bridge.` (gRPC) - [ ] Firewall rule: vault to `notary-bridge.` (HTTPS) - [ ] Firewall rule: Secure environment to container registry (image pull) **External proxy** - [ ] `HTTPS_PROXY` value documented - [ ] `NO_PROXY` exclusion list documented (cluster domain, API server, internal subnets) **TLS certificates** - [ ] CA certificate obtained - [ ] Server certificate and key generated for: - [ ] `api.` - [ ] `frontend.` - [ ] `openid.` - [ ] `notary-bridge.` - [ ] Certificates stored as Kubernetes TLS secrets (or secret manager references) ### Configuration reference For Helm values for certificates, proxy settings, and ingress, see [Networking configuration](/products/custody/v1.36/deployment/reference/networking) and [URL configuration](/products/custody/v1.36/deployment/reference/urls). ## Next step **Next:** [Secrets management planning](/products/custody/v1.36/deployment/planning/secrets).