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
andCRATEDB_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
andREVOKE
permissions to users or rolesControl 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
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