Security Guide
TDengine provides multi-layer security and reliability capabilities for production environments. This chapter is organized by a full-trace layered structure to show how authentication, transport encryption, compression, persisted-data protection, and high availability connect across taosX-Agent, taosX, taosAdapter, and taosd. Enterprise edition provides complete capabilities for user privileges (including RBAC / separation of duties), IP allowlists, audit, transparent encryption, and tokens. Community edition provides only basic capabilities; see each topic for details.
Reading Order
| # | Document | Topic |
|---|---|---|
| 01 | Full-Trace Authentication | Identity authentication and access control |
| 02 | Full-Trace Transport Security and Compression | TLS/SASL + transport compression + data-at-rest compression |
| 03 | Full-Trace Reliability | Checkpoint + WAL + backup and restore |
| 04 | Full-Trace Availability | Automatic failover + load distribution + active-active disaster recovery |
| 05 | Client and Connector Security | Token, client TLS, and dynamic rotation at the entry layer |
| 06 | Data-at-Rest Protection | TDE, key management, and SECURE_DELETE |
| 07 | Audit and Compliance | Audit log configuration and viewing |
| 08 | Security Hardening | Component exposure surfaces, hardening, and gateways |
| 09 | Security Advisories | Known vulnerabilities, affected versions, and fixed versions |
For syntax details, see Users and Privileges.
Unified Layered Framework
The following layers are the common narrative order for the full-trace topics:
+------------------------------------------------------------------+
| 1. Entry layer |
| A. Programmatic entry: applications / language connectors |
| (C / Python / JDBC / ODBC / Rust / Go / CSharp / Node.js) |
| B. Web UI entry: taosExplorer in a browser |
| C. CLI tools: taos / taosX / taosBenchmark / taosdump |
+------------------------------------------------------------------+
|
v
+------------------------------------------------------------------+
| 2. Access layer |
| Access layer = protocol/proxy layer after entry and before |
| taosd |
| Path A: client -> taosAdapter (WebSocket / REST) |
| Path B: client embeds taosc (native connection) |
| Both paths eventually enter taosd through taosc |
+------------------------------------------------------------------+
|
v
+------------------------------------------------------------------+
| 3. Data ingestion path (background tasks) |
| External source -> taosX-Agent (optional) -> taosX -> |
| taosAdapter -> taosd |
| taosX-Agent deployment does not change checkpoint semantics |
| Kafka / Pulsar can rely on upstream persistent buffering |
| Device-direct / edge-disconnect scenarios should use |
| taosX-Agent local buffering |
+------------------------------------------------------------------+
|
v
+------------------------------------------------------------------+
| 4. Cluster internals |
| taosd cluster (multiple DNodes / replicas / Leader switch) |
+------------------------------------------------------------------+
|
v
+------------------------------------------------------------------+
| 5. Observability access |
| taosKeeper receives metrics from components and writes them |
| into the log database |
+------------------------------------------------------------------+
|
v
+------------------------------------------------------------------+
| 6. Storage and audit persistence |
| Business data / audit logs -> WAL / snapshots / backup and |
| restore / TDE |
+------------------------------------------------------------------+
Layer Notes
- 1. Entry layer: user and application touchpoints, grouped as programmatic access, Web UI, and CLI.
- 2. Access layer: the two physical paths from entry to
taosd. Path A usestaosAdapterfor WebSocket/REST. Path B uses nativetaosc. Both eventually reachtaosdthroughtaosc. - 3. Data ingestion path: background data-flow tasks triggered by SQL in
taosd. The recommended model is "external source -> taosX-Agent (optional) -> taosX -> taosAdapter -> taosd". - 4. Cluster internals: multi-node, multi-replica, and Leader-switch mechanisms inside a
taosdcluster. - 5. Observability access:
taosKeeperreceives externally exposed metrics from components and writes them back to thelogdatabase. - 6. Storage and audit persistence: compression, encryption, logs, and backup mechanisms when business data and audit logs are persisted.
Key Terms
- Checkpoint resume: by default, checkpoint on the data source side, used to recover ingestion progress after task restart. It is different from the persistent queue used when
taosXwrites downstream. - Task restart: stopping and restarting a
taosXtask after all automatic fault-recovery mechanisms are exhausted. It is different from data source connection retry. - Node naming: product roles are written as
DNode,MNode, andVGroup; host examples such asdnode1are only address examples.
Applicable Versions and Conventions
- TDengine TSDB v3.4+
- Account examples use
tduser/SecurePass123!instead of the defaultroot/taosdata. - Domain examples use
example.com; certificate paths use/etc/taos/certs/.
For configuration and hardening, see Security Hardening. For vulnerability disclosure and fixed versions, see Security Advisories.