Configuration Reference
Every setting CBOM Secure reads at runtime, where it comes from, and what happens when it changes. This page is the reference companion to the Configuration page in the System Administration part, which explains the configuration model; this page lists the keys.
How configuration reaches a service
CBOM Secure holds its configuration in the database, not in files. The YAML files on disk are build products: on every configuration save, on activation and at startup, the platform writes the stored configuration out to the files each service reads.
Hand-edited YAML is overwritten. Because regeneration is wholesale, a section added by hand to a generated YAML file is removed the next time configuration is saved, and nothing reports the loss. Change configuration through System Configuration or the configuration API, never by editing the generated files.
Two documents hold everything:
| Document | Holds |
|---|---|
| Values document | The configuration values themselves. This is the single document fanned out to the per-service files. |
| Form document | The System Configuration page's field definitions. Each field names the value it edits. |
In a container deployment the first-start values come from environment variables, substituted into the configuration templates by each service's entrypoint. After first start, the database is authoritative and the environment variables are no longer consulted for those keys — change them in System Configuration.
Environment variables
Set in the deployment environment file before first start. Values marked secret must be generated per environment and must never be committed to source control.
Database
| Variable | Purpose | Secret | Default |
|---|---|---|---|
MONGO_ROOT_USER | Database administrative account | root | |
MONGO_ROOT_PASSWORD | Database administrative password | Yes | — |
MONGO_DB | Operational database name | CBOMData | |
MONGO_AUDIT_DB | Audit and history database name, on the same cluster | CBOMAudit | |
MONGO_HOST_PORT | Host binding for the database port | 127.0.0.1:27017 |
MONGO_HOST_PORT is a security control. The default binds the database to loopback, so only the server itself can connect; reach it from a workstation with an SSH tunnel. Setting 0.0.0.0:27017 exposes the entire database to the network with the root password as the only thing in front of it.
Ingestion broker
| Variable | Purpose | Secret | Default |
|---|---|---|---|
RABBITMQ_HOST | Broker address used by the platform services | rabbitmq | |
RABBITMQ_PORT | Broker port used by the platform services | 5672 | |
RABBITMQ_USER | Broker account the services and agents authenticate with | cbom | |
RABBITMQ_PASSWORD | Password for that account | Yes | — |
RABBITMQ_VHOST | Broker virtual host | / | |
RABBITMQ_TLS | Enable AMQPS | false | |
RABBITMQ_AGENT_HOST | Broker address written into every deployed agent's configuration | — | |
RABBITMQ_AGENT_PORT | Broker port written into every deployed agent's configuration | 5672 | |
RABBITMQ_HOST_PORT | Host binding for the broker port | 5672 | |
RABBITMQ_MGMT_USER | Management portal account, separate from the broker account | cbom-portal | |
RABBITMQ_MGMT_PASSWORD | Management portal password | Yes | — |
Keep the portal login distinct from the broker login. The broker credential ships in plaintext inside the configuration file on every host an agent is deployed to, and it carries the administrator tag. Anyone holding a deployed agent's configuration can therefore administer the broker. Leave both management variables blank to create no portal account at all.
Application
| Variable | Purpose | Secret | Default |
|---|---|---|---|
FLASK_SECRET_KEY | Session signing key; 64 random characters | Yes | — |
DEPLOYMENT_SECRET_KEY | Credential encryption key; must be a valid Fernet key | Yes | — |
PUBLIC_BASE_URL | Public address of the deployment | https://localhost | |
CBOM_SERVER_URL | Backend address, public-facing | https://localhost/cbomsrv | |
FRONTEND_URL | Console address | https://localhost | |
VITE_BACKEND_URL | API base the console calls | https://localhost/cbomsrv/api/v1 | |
CBOM_SERVER_ORIGIN | Backend origin, for the Content-Security-Policy allowlist | — | |
AI_SERVICE_ORIGIN | AI service origin, for the Content-Security-Policy allowlist | — | |
DOCKER_MODE | Marks containerised execution | true in containers |
Identity
| Variable | Purpose | Secret | Default |
|---|---|---|---|
KEYCLOAK_URL | Identity provider address used server-to-server | https://keycloak:8443/auth/ | |
KEYCLOAK_PUBLIC_URL | Identity provider address the browser is redirected to | https://localhost/auth/ | |
KEYCLOAK_REALM | Realm name | — | |
KEYCLOAK_CLIENT_ID | OIDC client identifier | — | |
KEYCLOAK_CLIENT_SECRET | OIDC client secret | Yes | — |
KC_ADMIN_USER | Identity provider administrative account | admin | |
KC_ADMIN_PASSWORD | Identity provider administrative password | Yes | — |
KEYCLOAK_SA_USERNAME | Backend service account, seeded by the realm import | cbom-service | |
KEYCLOAK_SA_PASSWORD | Backend service account password | Yes | — |
Both identity URLs must keep the /auth suffix. The identity provider is served under that sub-path, and dropping it from either address breaks the sign-in redirect in a way that reports only a generic failure.
Federated sign-in
| Variable | Purpose | Secret | Default |
|---|---|---|---|
AZURE_IDP_ENABLED | Enables the Microsoft sign-in option | false | |
AZURE_TENANT_ID | Entra ID directory identifier | common | |
AZURE_CLIENT_ID | Application registration identifier | — | |
AZURE_CLIENT_SECRET | Application registration secret | Yes | — |
First administrator
| Variable | Purpose | Secret | Default |
|---|---|---|---|
INITIAL_ADMIN_MODE | create provisions an administrator at first start; skip does nothing | skip | |
INITIAL_ADMIN_USERNAME | Account name | — | |
INITIAL_ADMIN_EMAIL | Account email | — | |
INITIAL_ADMIN_FIRST_NAME | Given name | — | |
INITIAL_ADMIN_LAST_NAME | Family name | — | |
INITIAL_ADMIN_PASSWORD | Initial password | Yes | — |
With INITIAL_ADMIN_MODE=skip, the first administrator is instead created by promoting a user after their first federated sign-in. Choose that path for organisations that do not want a password account to exist at all. The bootstrap is idempotent either way: it does nothing if an administrator already exists.
Agent-facing addresses
These three values are written into the configuration of every deployed agent, so each must resolve from the target machine — not from inside the platform network, and not from the platform host.
| Variable | Purpose | Default |
|---|---|---|
COLLECTOR_SERVER_URL | Result submission address | https://localhost/collector |
RABBITMQ_AGENT_HOST | Broker address for result publication | — |
CBOM_SERVER_URL | Backend address; also serves the sign-in redirects | https://localhost/cbomsrv |
A loopback value here names the agent, not the platform. The deployment reports success, the scan runs, and the results are never delivered. Replace localhost with an address the targets can actually reach before deploying to anything other than the platform host itself.
AI services
| Variable | Purpose | Secret | Default |
|---|---|---|---|
AI_PROVIDER | Model provider: anthropic, openai, google, groq, ollama or lmstudio | anthropic | |
AI_MODEL | Model identifier | — | |
AI_API_KEY | Provider API key | Yes | — |
OLLAMA_BASE_URL | Local provider address; ignored for hosted providers | — | |
LMSTUDIO_BASE_URL | Local provider address; ignored for hosted providers | — |
Without an API key the service starts and the page loads, but questions fail at the provider. These values seed the first start only; change them in System Configuration afterwards. See the AI Services Data Handling page for what leaves the deployment boundary under each provider setting.
Discovery and observability
| Variable | Purpose | Default |
|---|---|---|
LOCAL_DISCOVERY_URL | Address of the bundled discovery server, when the stack runs one | http://discovery-server:5002 |
OTLP_ENDPOINT | Telemetry collector address | otel-collector:4317 |
GRAFANA_ADMIN_USER | Telemetry dashboard administrative account | admin |
GRAFANA_ADMIN_PASSWORD | Telemetry dashboard administrative password — required | — |
CBOM_SCHEDULER_ENABLED | Enables the scheduled-task runner | unset |
GRAFANA_ADMIN_PASSWORD has no safe default. The telemetry dashboard is routed publicly, so without this value the stack would come up reachable on a well-known default credential.
Settings changed after installation
The following are edited in System Configuration rather than in the environment file. Each is stored in the values document and fanned out to the services that read it.
| Area | What it controls |
|---|---|
| Session | Session lifetime and the interval of the expiry sweep. |
| Logging | Log level per domain, handler destinations and file paths. |
| Deployment | The collector address written into agent configuration, and remote-delivery timeouts. |
| Discovery | Registered discovery servers and their addresses. |
| AI service | Provider, model, API key, response detail and topic-guard behaviour. |
| Interface | Console defaults, help and support links. |
| Broker | Ingestion broker address, credentials and virtual host. |
Two settings are deliberately not exposed in System Configuration:
| Setting | Why it is not editable from the console |
|---|---|
| Authorisation mode | It governs the permission check that protects the System Configuration page itself. A page that authorisation protects must not be able to switch authorisation off. |
| Broker TLS | Enabling it would move the platform to AMQPS while every already-deployed agent stayed on plain AMQP, so result publication would stop silently until someone read an agent log. Broker TLS is delivered together with the per-host client certificates that make it worth having. |
Restart behaviour
| Change | Effect |
|---|---|
| Any value saved in System Configuration | Written to the database, fanned out to the service files, and the affected service restarted by the configuration watcher. |
| Log level and handler changes | Applied on the affected service's restart. |
| Agent-facing addresses | Applied to newly deployed agents. Already-deployed agents keep the address they were built with; redeploy the task to update them. |
| Environment file changes after first start | Not consulted for keys the database already holds. Change those in System Configuration instead. |
Files written
For reference when diagnosing a deployment. These are outputs; do not edit them.
| File | Read by |
|---|---|
| Root configuration | Every service, for shared database and identity settings |
| Backend service configuration | The API and analysis service |
| Collector service configuration | The ingestion service |
| Discovery server configuration | The discovery service |
| Console configuration | The console's runtime settings |
| AI service configuration | The AI service |
Configuration destined for the console and the AI service is written unwrapped — its contents go to the top level of the target file rather than under a section key, because that is what those services read. A configuration file that parses cleanly but in which a service finds none of its settings is the symptom of that distinction being lost.