Documentation

2.1 Deployment Topologies

This part covers how to deploy CBOM Secure: the supported topologies, the prerequisites to satisfy before starting, the installation procedures themselves, troubleshooting for the failures that occur during installation, and a validation checklist to sign off against.

Two deployment styles are covered: a containerised deployment orchestrated by Docker Compose, which is the recommended path, and a native service deployment on Linux, for environments where containers are not permitted.

A topology page exists to answer three questions before installation begins: which components land on which machine, what talks to what, and which ports must be opened. It is a technical reference, not a procedure.

2.1.1 Single-Node (All-in-One) Topology

Every platform service runs on one machine. Suitable for proof of concept, evaluation, and small estates.

On the node: reverse proxy, frontend, CBOM-Server, Collector-Services, deployment server, discovery server, MongoDB, Keycloak, message queue, and the logging pipeline.
Exposed to the network: the reverse proxy port only.
Outbound from the node: to scan targets (TLS, SSH, WinRM, SMB, cloud provider APIs, database ports, HSM ports) and to any configured integration endpoint.
Trade-off: a single failure domain, and discovery load competes with portal and database load on the same host. Acceptable for evaluation, not for a production estate of any size.

2.1.2 Distributed Topology

For production, the platform separates along its natural service boundaries. The separation to make first is discovery from everything else, because discovery is the component whose load is unpredictable and whose network reach must be widest.

Frontend and API tier: reverse proxy, frontend assets, CBOM-Server. Handles interactive load. Scales horizontally behind the proxy.
Ingestion tier: Collector-Services and the message queue. Sized to the sensor fleet, and placed where remote sensors can reach it. This is the tier that may sit in a DMZ.
Discovery tier: discovery server and deployment server. Placed where it can reach scan targets. Needs the widest outbound firewall allowance and the narrowest inbound.
Data tier: MongoDB. Deploy as a replica set for availability. Holds both the operational and audit databases.
Identity tier: Keycloak, with its own datastore.
Observability tier: OpenTelemetry collector, Loki and Grafana.

The design property that makes this work is that the collector holds no business logic and writes only to a staging collection. Placing it in a lower-trust zone therefore does not expose the inventory, the policy set or the configuration.

2.1.3 Component Placement Guidance

Place the ingestion tier where the largest number of sensors can reach it without a firewall change. Sensors initiate; the collector never calls back.
Place the discovery tier close to the densest population of scan targets, to minimise the number of firewall rules and reduce scan latency.
Keep MongoDB off the internet-facing tier under all circumstances. It is never routed through the proxy.
Co-locate the audit database with the operational database but keep it as a separate database, so that retention and access rules stay separable.
Place the observability tier wherever every service can emit to it. It needs no inbound access from outside.

2.1.4 Network Traffic Flow

Traffic falls into three groups — external ingress, internal service traffic, and outbound scan egress. Each is listed explicitly below, so that a network team can produce firewall rules directly from it.

External ingress

Interactive users and API clients: HTTPS to the reverse proxy port. Routed by path prefix to the frontend, CBOM-Server, or Grafana.
Remote sensors: HTTPS to the reverse proxy, routed to Collector-Services only. Sensors need no access to any other path, and the proxy configuration should enforce that.

Internal service traffic

Proxy to frontend, CBOM-Server, Collector-Services and Grafana.
CBOM-Server and Collector-Services to MongoDB.
CBOM-Server to Keycloak, for token validation and realm administration.
Emitters and Collector-Services to the message queue, when queue-based ingestion is in use.
All services to the OpenTelemetry collector; the collector to Loki; Grafana to Loki.

Outbound scan egress

TLS scanning: to target ports, commonly 443 and any other TLS service port in scope.
SSH scanning and Linux deployment: port 22 to targets.
Windows deployment: WinRM on 5985 or 5986, and SMB on 445 to targets.
Cloud sensors: HTTPS to the relevant cloud provider management and key service endpoints.
Database sensors: to the relevant database listener ports.
HSM and key manager sensors: to the relevant PKCS#11, KMIP or vendor API ports.
Directory sensors: LDAP on 389 or LDAPS on 636.
Integrations: HTTPS outbound to the EDR, ticketing and notification endpoints configured.

CBOM Secure