Security

CrateDB is designed with security in mind to support both on-premises and cloud-native deployments. Whether you're deploying CrateDB yourself or using CrateDB Cloud, you can secure your data with authentication, access control, encryption, and best practices.

This page outlines how CrateDB handles security and what you can do to configure and monitor it effectively.

Table of Content


🔐 1. Authentication

CrateDB Cloud

CrateDB Cloud supports:

  • OAuth2-based authentication via the CrateDB Cloud console

  • API key-based authentication for CLI and programmatic access

  • Environment variable support for headless authentication (CRATEDB_CLOUD_API_KEY and CRATEDB_CLOUD_API_SECRET)

→ See: Using Croud CLI – Authentication

Self-hosted CrateDB

In self-hosted environments, CrateDB supports SQL-based user authentication:

  • Create users with CREATE USER

  • Set passwords with ALTER USER ... SET (password = '...')

  • Users are authenticated over the PostgreSQL wire protocol or HTTP


🛡️ 2. Role-Based Access Control (RBAC)

CrateDB implements fine-grained role-based access control (RBAC) to manage permissions.

Organization and Project Roles (Cloud)

Roles are scoped at the organization or project level:

  • Organization Admin: Full access across the organization

  • Organization Member: Read-only access

  • Project Admin: Manage project settings, users, clusters

  • Project Member: Read-only access to project resources

→ See: Croud CLI – User Roles

SQL Privileges (Self-hosted)

CrateDB supports SQL-based grants:

  • GRANT and REVOKE permissions to users or roles

  • Control access at the level of tables, schemas, and columns

  • Example: GRANT DQL, DML ON TABLE my_table TO user1


🔒 3. Encryption

In Transit

CrateDB supports TLS encryption for secure communication between:

  • Clients and the CrateDB HTTP/SQL interfaces

  • CrateDB nodes in the same cluster (for Cloud deployments)

Self-hosted users must configure TLS manually via the ssl settings in crate.yml.

At Rest

  • CrateDB Cloud: Data is encrypted at rest using encrypted volumes provided by the cloud infrastructure provider (Azure, AWS, GCP).

  • Self-hosted CrateDB: You can use filesystem-level encryption or encrypted disks.

→ See: CrateDB Cloud Encryption at Rest


🕵️ 4. Auditing and Monitoring

CrateDB Cloud provides:

  • Activity logging via the CrateDB Cloud Console

  • API usage monitoring through the CLI and console

  • Integration with third-party observability tools (e.g., Prometheus, Grafana)

Self-hosted users can configure:

  • Logging levels and log destinations

  • Query log inspection for audit trails

  • Metrics endpoints for Prometheus


⚙️ 5. Secure Deployment Practices

CrateDB Cloud

  • Runs on hardened infrastructure managed by the CrateDB team

  • Follows DevSecOps best practices with regular updates and monitoring

  • Isolated environments per organization and project

Self-hosted

Recommended practices:

  • Disable unused ports and bind CrateDB only to internal IPs

  • Secure admin interfaces

  • Enforce strong user passwords

  • Rotate credentials and keys regularly

  • Keep CrateDB updated with the latest version and security patches

→ See: Deployment Guidelines


🧪 6. Penetration Testing & Compliance

CrateDB Cloud undergoes regular security reviews and penetration testing by external firms.

Compliance standards include:

  • GDPR-ready design

  • Data locality controls via regional deployments

  • Support for privacy-preserving design (e.g., role separation, access policies)


✅ Summary

Feature
CrateDB Cloud
Self-hosted CrateDB

User authentication

OAuth2, API keys

SQL users & passwords

Access control (RBAC)

Org & project roles

SQL GRANT/REVOKE

Encryption in transit

Enabled by default

Configurable via TLS

Encryption at rest

Cloud provider-based

Manual disk encryption

Audit & activity logs

Built-in

Manual via logging setup

Penetration testing

Regular, by CrateDB

User responsibility

Last updated