---
title: Security Documentation
description: Canonical makes open source secure, reliable and easy to use, providing
  support for Ubuntu and a portfolio of enterprise-grade technologies. Founded in
  2004, Canonical operates globally with team members in over 80 countries.
url: https://canonical.com/dqlite/docs/reference/security?format=md
---

*Submit*

# Security Documentation

## [Architecture](https://canonical.com/dqlite/docs/reference/security?format=md#p-588-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](https://canonical.com/dqlite/docs/reference/security?format=md#p-588-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](https://canonical.com/dqlite/docs/reference/security?format=md#p-588-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](https://canonical.com/dqlite/docs/reference/security?format=md#p-588-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](https://canonical.com/dqlite/docs/reference/security?format=md#p-588-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 `dqlite` stores these)

## [Security lifecycle](https://canonical.com/dqlite/docs/reference/security?format=md#p-588-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](https://canonical.com/dqlite/docs/reference/security?format=md#p-588-reporting-vulnerabilities-and-bugs)

All bug reports are welcome! Please be aware of the [`dqlite` security policy](https://github.com/canonical/dqlite/blob/main/SECURITY.md) and the [Ubuntu Security disclosure and embargo policy](https://ubuntu.com/security/disclosure-policy).

When vulnerabilities are found, we document them in the relevant release notes.

---

[Previous

Explanation:
FAQ](https://canonical.com/dqlite/docs/explanation/faq)
[Next

Wire Protocol](https://canonical.com/dqlite/docs/reference/wire-protocol)

Last updated 2 months ago. [Help improve this document in the forum](https://discourse.dqlite.io/t/security-documentation/521).