Security

This page summarizes CockroachDB's trust boundaries and the code that enforces them. For implementation details, see systems/security and systems/rpc.

Trust boundaries

CockroachDB recognizes the following actors:

Actor	How it authenticates	Where enforced
SQL client	Cert / password / JWT / OIDC / LDAP / GSS	pkg/sql/pgwire/auth.go
HTTP client	Session cookie / bearer token	pkg/server/authserver/
Inter-node RPC	Mutual TLS with node cert	pkg/rpc/auth.go
Tenant SQL pod	Mutual TLS with client-tenant.<id> cert	pkg/rpc/auth_tenant.go
Tenant capability	Server-side capability check	pkg/multitenant/tenantcapabilities/

TLS

Mutual TLS is on by default for all inter-node and HTTP traffic. The cockroach cert family of subcommands generates the certificate hierarchy:

• ca.crt — single cluster CA.
• node.crt / node.key — node certificate.
• client.<user>.crt — per-user client cert.
• client-tenant.<id>.crt — per-tenant client cert.

--insecure mode disables TLS and is only suitable for testing. Production clusters must use TLS.

SQL authentication

The selected method per (host, user, db) is governed by server.host_based_authentication.configuration (an HBA-config string) plus optional server.identity_map.configuration for cert-CN→user mapping. Supported methods:

• cert (default for CRDB-issued client certs).
• password (SCRAM-SHA-256 hashes; bcrypt fallback).
• jwt_token (validated by pkg/security/jwtauth/).
• gss (Kerberos; CCL).
• ldap (bind + group→role mapping).

Authorization

CRDB implements PostgreSQL-style role and privilege model with extensions:

• Roles inherit privileges; INHERIT/NOINHERIT per role.
• GRANT/REVOKE on databases, schemas, tables, types, schedules, routines.
• System-level privileges (MODIFYCLUSTERSETTING, VIEWACTIVITY, CONTROLJOB, MANAGETENANT, …) are defined in pkg/sql/syntheticprivilege/.
• pkg/sql/sqlerrors/ produces consistent permission-denied messages.

Multi-tenant clusters add tenant capabilities (pkg/multitenant/tenantcapabilities/): a coarse, host-controlled list of which host APIs (e.g. can_admin_split, can_view_node_info, can_use_nodelocal_storage) a tenant may exercise.

Encryption at rest

Optional encryption-at-rest for store data uses customer-managed keys via pkg/storage/encryption.go (interface) and pkg/ccl/storageccl/engineccl/ (implementation). Key rotation is supported by writing keys to a JSON file referenced by --enterprise-encryption. Keys are AES-256.

Audit logging

pkg/util/log/'s channels separate audit-relevant messages (USER_ADMIN, PRIVILEGES, SESSIONS) from operational ones. The crdb_internal.event_log table records administrative events, and SQL audit logging can be enabled per table via ALTER TABLE … ENABLE AUDIT.

FIPS

A FIPS 140-2 build (pkg/security/fips/, pkg/cli/debug_fips.go) restricts cipher suites and uses BoringCrypto-backed Go for cryptographic operations. Distinct release artifacts are produced for FIPS deployments.

Secrets

CRDB does not store secrets in plain text in its config. SCRAM hashes are stored Postgres-compatibly. JWT signing keys are referenced by URL and not embedded. system.users.pwhash carries SCRAM strings. Cluster settings classified protected (e.g. cloud-storage credentials in system.settings) are encrypted at the per-cluster level.

Reporting vulnerabilities

The repo's SECURITY.md and the published security policy at https://www.cockroachlabs.com/docs/stable/security-overview.html are the canonical contact points.

Related pages

• systems/security — implementation.
• systems/rpc — TLS connection plane.
• api/pgwire — client authentication.
• features/multi-tenant — tenant capabilities.