Security Documentation
Architecture
The communication flow between clients and nodes in a working dqlite cluster is shown below. All arrows shown are network communications, the boundary of trust is considered to be at the level of each node. To minimise external interference, nodes always communicate via TLS.
The RAFT algorithm at the heart of dqlite does not account for rogue nodes, therefore, applications which deploy dqlite must:
- Ensure that arbitrary nodes cannot enter the cluster
- Access to the underlying nodes running dqlite is restricted to a very small number of trusted, privileged users.
Logging and Monitoring
By default, dqlite logs when the system is restarted, when nodes are lost and when new nodes come online. Logs also show the types of messages exchanged between cluster nodes.
Cryptography
dqlite itself does not use any cryptographic technologies. The transfer of data between nodes during replication is the responsibility of the driver. In the go-dqlite driver, for example, data is transferred over a socket secured with TLS.
Hardening guidelines
If sensitive data is stored within a dqlite database, ensure that it is not usable in the form stored (e.g. no plain-text passwords). Dqlite does not protect against an someone manually inspecting the underlying SQLite database.
Decommissioning a dqlite instance
To delete a dqlite database, be sure to:
- Delete the main database file
- Delete the write-ahead log (
*.db-wal), next to the main file - Delete the shared memory map (
*.db-shm), next to the main file - Delete any logs (check where the system integrating
dqlitestores these)
Security lifecycle
Dqlite maintains LTS versions where Canonical products require it. In particular, we release LTS versions to support:
- LXD
- Canonical K8s
- Juju
- Anbox
Reporting vulnerabilities and bugs
All bug reports are welcome! Please be aware of the dqlite security policy and the Ubuntu Security disclosure and embargo policy.
When vulnerabilities are found, we document them in the relevant release notes.