Skip to main content
This page summarizes the security controls in Airhouse and what you configure yourself when you deploy it.

​
Authentication

  • SCRAM-SHA-256 for every wire-protocol connection, the same password mechanism modern PostgreSQL uses.
  • No plain-text passwords at rest. Passwords for database users and minted credentials are stored as SCRAM verifiers.
  • Short-lived credentials. Service accounts mint per-user credentials that expire after at most 24 hours and can be revoked individually. A service-account bearer can only mint for its own database, capped at its max_role and max_ttl_secs. Only a hash of the bearer is stored.
  • Admin API tokens. The Admin API requires a bearer token on every request. Keep the admin token on your servers only.
  • Fail closed. If Airhouse can’t reach its user registry, it rejects logins (SQLSTATE 53300) instead of letting them through. If it can’t determine a session’s role, it closes the connection instead of running with reduced privileges.

​
Authorization

  • Roles on every statement. reader, writer, and admin are checked before a statement reaches the query engine. See Users, roles, and security.
  • Schema-scoped writers. Credentials can be limited to writing in named schemas. See Schema-scoped writers.
  • Extension allowlist. Users can only INSTALL or LOAD DuckDB extensions the operator allows.

​
Encryption

  • In transit, clients: enable TLS on the server with a certificate and key ([tls], or tls in the Helm chart), and connect with sslmode=require or stricter. With the Helm chart, TLS passes through HAProxy to the data plane.
  • In transit, Postgres: the Helm chart connects to the registry and catalog servers with sslmode=require by default.
  • In transit, object storage: set use_ssl (S3_USE_SSL) to use HTTPS to your storage endpoint.
  • At rest: Airhouse stores data in your object storage and Postgres. Use their encryption at rest, such as server-side encryption on the bucket and encrypted Postgres storage.

​
Isolation

  • Between databases. Each database has its own catalog, its own Postgres role, its own storage prefix, and its own users. See Multi-tenancy.
  • Between connections. Each connection runs in its own DuckDB session, and per-user and per-database limits stop one workload from starving others.
  • Your infrastructure. Airhouse runs in your environment. Your data doesn’t leave your storage and Postgres. See Where your data lives.

​
Auditing

Airhouse records executed queries, including the user, duration, row count, and outcome, in an audit log. Each credential minted by a service account gets its own unique username, and Airhouse stores it with the subject your platform supplied and the issuing service account. Because the audit log records the username, you can trace each query back to one of your users.

​
Your responsibilities when you deploy

  • Replace every default password and token. Generate the admin token with openssl rand -hex 32 and store it in a secret manager.
  • Enable TLS for any client traffic that crosses a network you don’t control.
  • Keep port 8080 (Admin API) reachable only from trusted networks.
  • Restrict access to the bucket and the Postgres servers to Airhouse and your administrators.
  • Give each user the lowest role that works, and prefer short-lived credentials for applications.