Security overview
How TeselaDB protects data on the network, on disk and from users.
TeselaDB starts secure: TLS on every port, required users and authorization on every command. Here is each layer and where it is configured.
How it works
Each request goes through several layers of security, from the moment it reaches the network until it is written down in the audit log. Each layer is configured on its own, with its own options.
Network
The client port only accepts TLS. Between nodes the cluster speaks TLS 1.3 with a certificate at both ends, and both certificates have to be signed by the cluster CA, so a machine without that certificate can neither join nor read the traffic.
Identity
Drivers authenticate with MongoDB's mechanisms, from SCRAM to OIDC. The REST API and the MCP server use API keys, which carry at most the roles of the user who created them.
Authorization
Before reading the fields of a command, the node checks that the user holds the privileges that command asks for on that database and that collection.
Disk
Start the node with --enableEncryption and everything it stores on disk is encrypted: the documents, the indexes and
the write log.
Sensitive fields
With Queryable Encryption, the driver encrypts the fields you mark before sending them, and the server never sees their value in clear text, not even when it searches on them.
Log
Auditing records each authentication and each denied authorization. It also records the changes to the catalogue and those to the users and their roles.
What it means for your application
Your application needs a user of its own with just the roles it needs and the cluster CA. Passwords and private keys never appear in logs or metrics.
Limits
--insecure drops TLS and users for local tests and only listens on 127.0.0.1. There is no way to turn authorization off on a secure node.