Skip to main content

Security overview

This page maps the four pieces of ScramDB's security model and points you at the one setting most deployments need to change before they see real traffic. By the end you will know what ScramDB enforces today, what it does not enforce yet, and where to go for each piece.

The four pieces​

Authentication. Every connection that isn't explicitly trusted by a host-based rule proves its identity with a SCRAM-SHA-256 password, the same mechanism PostgreSQL itself uses by default. Roles, passwords, and the pg_hba.conf-style rule file that decides who gets asked for a password (and who doesn't) are covered in Authentication.

TLS. The PostgreSQL wire-protocol connection can be encrypted with a server certificate you provide. Once tls_cert and tls_key are set, ScramDB refuses to start on a broken certificate rather than silently falling back to plaintext. See TLS encryption.

Roles and privileges. ScramDB speaks PostgreSQL-compatible CREATE ROLE, GRANT, REVOKE, and row-level security policies. Table and column grants are enforced on every query; row-level security policies filter rows per role. See Roles and privileges for exactly what is checked, and what is parsed but not gated yet.

Sandboxing. Every user-defined function, in every supported language, runs inside a sealed WebAssembly module with no filesystem, network, subprocess, or environment access, regardless of what the module's own package manifest asks for. Resource caps bound how much fuel, memory, wall-clock time, and output a single call can consume. See Production hardening checklist for the details, including the one language pair that doesn't get the same resource caps yet.

The one thing to fix first​

The published Docker image and the shipped Kubernetes StatefulSet both start with authentication turned off. The container's default command is --pg-address 0.0.0.0:5432 --pg-no-auth: it listens on every network interface and trusts any connection with any username, no password required. This is deliberate, it's what makes docker run and a five-minute quick start frictionless, but it is not a posture to carry into production.

The engine itself does not default this way. With no flags and no config file, ScramDB binds to 127.0.0.1:5432 only, with authentication on. The open bind and disabled auth both come from the image's own startup command, not from the engine. Fixing it is one flag: see Docker: Securing a node for the exact command, and Authentication for what happens once auth is on.

What is not covered yet​

Ship what's real, not what's implied. ScramDB does not currently ship:

  • Any authentication method besides SCRAM-SHA-256 password auth. There is no LDAP, Kerberos, GSSAPI, or OAuth integration, and no distinct md5 method (see Authentication).
  • Client-certificate (mTLS) authentication. TLS encrypts the wire; the server never requests or verifies a client certificate (see TLS encryption).
  • A password complexity or expiry policy. VALID UNTIL on a role parses and is stored, but nothing checks it at login time yet (see Roles and privileges).
  • Enforced CONNECTION LIMIT on a role, or schema-level CREATE privilege gating. Both parse and store correctly; neither is checked by any code path yet.

None of this is silently bypassed: ScramDB doesn't pretend to enforce something and then skip it. A feature in this list simply isn't wired to a check yet, and this page says so plainly rather than leaving you to find out the hard way. When you're ready to go to production, Production hardening checklist turns all of this into a concrete list of changes.