OpenShift on ZopNight: Connect Private Clusters Without Opening Inbound Ports
A private API server keeps the Kubernetes control plane off the public internet. Every tool that needs API access must either run inside the network or require an inbound path through the firewall. Most teams with a private API server reject the inbound path. The monitoring tool loses access, and the cluster runs without external visibility.
ZopNight now connects to self-managed OpenShift clusters that run a private API server. The customer deploys a small network agent on a VM in their own network. The agent connects outbound to ZopNight, so no inbound port ever opens. Once connected, discovery, live view and recommendations work the same way they do for a public cluster.
The Agent Runs Inside the Network and Connects Out
The network agent sits on a VM in the same network as the OpenShift cluster. It reaches the private API server through local traffic, the way any internal service would. It then opens an outbound connection to ZopNight.
| Connection model | Who initiates | Inbound port required |
|---|---|---|
| Public API server | ZopNight connects to the cluster | No (API already reachable) |
| Private API server with agent | Agent connects to ZopNight | No (outbound only) |
Both models require zero inbound firewall changes. For a public cluster, ZopNight reaches the API server directly. For a private cluster, the agent starts the connection from inside the customer’s network. All traffic between the cluster and ZopNight flows through the agent, and the direction is always outbound from the customer’s side.
The customer opens no inbound ports, exposes no endpoints, and changes no firewall rules. Teams using role-based access controls to limit who modifies infrastructure keep the same controls. Connecting the cluster does not change the network boundary.
Discovery, Live View and Recommendations Match a Public Cluster
Once the agent connects, ZopNight treats the private OpenShift cluster like any other connected cluster. The platform discovers workloads, provides a live view of cluster state, and generates recommendations. These three capabilities work the same whether the API server is public or private.
| Capability | Public cluster | Private cluster with agent |
|---|---|---|
| Discovery | Yes | Yes |
| Live view | Yes | Yes |
| Recommendations | Yes | Yes |
There is no reduced feature set for private clusters. The agent bridges the network gap so ZopNight accesses the same Kubernetes API surface it would reach on a public cluster. Teams that run recommendation approval policies or auto-remediation rules on public clusters get the same workflows on private OpenShift.
Private clusters often carry the workloads with the strictest operational requirements. Full feature parity means those workloads get the same recommendations and live view as anything running on a public endpoint. A ZopNight account can connect a mix of public and private clusters without a separate process for each type.
The Agent Is the Only Path to the Private Cluster
The agent on the customer’s VM is the single connection between ZopNight and the private API server. ZopNight cannot reach the cluster directly. If the agent stops running, the connection is not available until it restarts.
Teams that rely on continuous discovery and live view for compliance audit findings should treat the agent VM like other monitoring infrastructure. The agent is a small process, but the cluster’s visibility in ZopNight depends on it staying up.
