User Guide

Security

Security overview

Montycat combines multiple layers of security by default: safe API design, TLS, encrypted credentials, system file integrity, and enforced secret management.
While other databases offer some of these features individually, Montycat integrates them seamlessly, making it easier to deploy a secure database out-of-the-box—and reducing reliance on user configuration.

From eliminating raw database injections to providing native encryption in transit, Montycat ensures your data remains safe and confidential.
Montycat does not allow raw queries, which eliminates the risk of SQL-style injection attacks present in many legacy databases.
All operations are performed through safe, structured APIs, ensuring that user inputs cannot directly manipulate the underlying database engine.
Montycat has native TLS support, encrypting all communication between the database server and its clients.
Enabling TLS ensures that data in transit cannot be intercepted or tampered with.

Enabling TLS

montycat tls-paths --cert <absolute path> --key <absolute path>

or

montycat console
> tls-paths cert <absolute path> key <absolute path>

exit

Make sure the certificate and key files have the correct permissions on UNIX-based systems.
Within Docker, you can set TLS paths using environment variables, and mount the certificate files as volumes.

FROM montygovernance/montycat:latest

# MONTYCAT_TLS_CERT and MONTYCAT_TLS_KEY paths

ENV MONTYCAT_TLS_CERT=/path/to/tls.crt
ENV MONTYCAT_TLS_KEY=/path/to/tls.key

Connecting clients with TLS

TLS must also be enabled by the client. The setting applies to regular commands and subscriptions.

from montycat import Engine

connection = Engine(
    host="db.example.com",
    port=21210,
    username="USER",
    password="PASSWORD",
    store="Company",
    tls=True,
)

Self-signed certificates

Montycat can generate its own certificate, so an install can serve encrypted traffic without a certificate authority, an openssl binary, or a mounted certificate. Generation happens inside the engine and writes the key with 0600 permissions and the certificate with 0644.

There are two ways to trigger it. Set MONTYCAT_INIT_SELF_TLS=true and the certificate is generated at startup before any listener binds, so TLS is active on that same run — this is the right choice for containers. Or run init-self-tls in the console on a server that is already up; that reaches listeners which are already bound, so it reports restart_required and TLS activates on the next restart.

Both are idempotent: existing certificate material is never replaced unless force is given explicitly (MONTYCAT_TLS_FORCE=true, or force true in the console). Restarting a container does not churn the certificate.

FROM montygovernance/montycat:latest

# Generate a self-signed certificate on startup, before any listener binds.
# Only this variable is required; the rest are optional.
ENV MONTYCAT_INIT_SELF_TLS=true

# Identities clients will use. 0.0.0.0 is a bind address, not an identity,
# so put the address clients actually dial here.
ENV MONTYCAT_TLS_IP_ADDRESSES=192.168.1.20
ENV MONTYCAT_TLS_DNS_NAMES=montycat,db.example.com

ENV MONTYCAT_TLS_VALIDITY_DAYS=365
ENV MONTYCAT_TLS_FORCE=false

File system

All system files in Montycat are hashed and monitored for integrity.
Any unauthorized access attempts or manual modifications to configuration or system parameters will be detected immediately and result in startup failures or operational errors, ensuring that tampering is prevented and the system remains secure.

Montycat encrypts credential files and other sensitive system files automatically.
During startup:

• Montycat reads the initial secret stored locally.
• Decrypts credentials and system files.
• Loads them into memory for runtime usage.

This default approach is suitable for testing and development but not recommended for production.

Recommended Production Setup:

• Use a dedicated environment variable with a strong secret.

You can generate a new secret

montycat generate-new-secret

or

montycat console
> generate-new-secret

exit

Example output (44-character random secret):
Yp9KfAq2VWxB3j7N9GhRtUb5MzLsQeDcXo1K8nZyPwEr

Setting the Production Secret:

montycat console
> set-prod-secret <secret>

exit

This command removes the initial Montycat secret file.
The new secret is temporarily stored as a local environment variable.
For production, you must set it globally at the system level, otherwise Montycat will not start.

Set secret variable with Docker.

FROM montygovernance/montycat:latest

MONTYCAT_PROD_SECRET=<your_secret>

Role-Based Access Control (RBAC)

Montycat includes fine-grained role-based access controls for managing database privileges:

• Superowner — has full control over the database, including system-level operations and ownership delegation.
• Owners — responsible for specific resources. Owners cannot override superowner privileges but maintain full autonomy over their assigned domains.

This ensures separation of duties, prevents privilege escalation, and provides administrators with enterprise-grade access control built-in by default.

Best Practices for Maximum Security

Always use TLS in production to encrypt all traffic.
Use strong, randomly generated secrets for credentials encryption.
Do not store secrets in plaintext; prefer environment variables or secure vault solutions.
Restrict file permissions on key and certificate files to minimize exposure.
Regularly rotate secrets and certificates for ongoing security compliance.
Apply Montycat's RBAC model to enforce least-privilege and reduce insider risk.