# Security of the cluster API

## The cluster API is unauthenticated and assumes private infrastructure

**Id:** bfadc31c-b5f3-4591-8805-8d62f446d8d0
**Type:** decision
**Type:** constraint
**Status:** active
**Evidence:** confirmed
**Source:** maintainer, 2026-10-07; README "Security caveats"
**Revisit when:** UBDCC gets a noticeably larger user base, or development of the cluster resumes

UBDCC's REST endpoints have no authentication and no transport
encryption. That includes the internal ones: `/ubdcc_mgmt_backup`
answers on every pod, the public restapi included, and returns the full
cluster DB with the Binance API secrets in cleartext; a `POST` to it
replaces the DB. `/ubdcc_assign_credentials` hands a full key pair to
whoever asks on the mgmt port. Public responses (`get_cluster_info`,
`get_credentials_list`) only show masked key previews.

**Reason:** the keys have to be distributed inside the cluster — every
DCN needs a full pair, and the DB is replicated to every pod so the
self-healing backup flow survives a mgmt restart. Exposing full
secrets on the internal paths is therefore partly inherent to the
design, not an oversight. The protection boundary is the network: the
documentation says throughout that a cluster belongs on private
infrastructure (firewall, private VPC), never reachable from the public
internet.

**Rejected alternative:** authentication and encryption on the
cluster's internal API. Not rejected on the merits but deferred: the
project currently has few users and is on hold, and that work only
pays off once more people run clusters — the README already says the
project is "building from the core outward".