Licensed to be used in conjunction with basebox, only.
// security
Encryption
Applies to
Product: Demo · Cloud · Server · Audience: Security / Compliance reviewer
TLS in transit (ingress, AISRV↔inference, connectors, directory, mail), encryption at rest and key management. The honest short version: in transit everything can be encrypted and is encrypted in production; at rest the application currently does not encrypt by itself – the storage layer does that, and your security concept must say so.
In transit
| Path | Encryption | Configuration (Server) |
|---|---|---|
| Browser / API client → ingress | HTTPS (TLS) – mandatory in production | TLS mode in the chart: cert-manager (automatic certificates), existing-secret (own certificate, also from an internal CA), local only for evaluation – Using Helm charts |
| Frontend → Keycloak (OIDC) | HTTPS via the same ingress (/auth) |
VITE_BB_OIDC_DOMAIN with HTTPS address |
| AISRV → inference | Inside one cluster internal service traffic; TLS as soon as the path crosses hosts or security zones – then mandatory | AISRV_LLM_URL with https://; import the private CA into the basebox workload (Connect inference) |
| AISRV → ragsrv → ragsrv-support | Internal cluster traffic with API keys | – |
| MCP connector → target system | System-specific, usually HTTPS; IMAP via 993 (TLS) | Base URLs with https://; target system certificates from a public or agreed private CA |
| Web search connector → search provider | HTTPS to the provider hosts (api.staan.ai) |
Egress allowlist at the gateway |
| Keycloak → LDAP | LDAPS (636) recommended; StartTLS possible; 389 unencrypted only inside a protected network | LDAP |
| AISRV → SMTP | STARTTLS (587) or TLS (465) | AISRV_SMTP_* |
| Services → PostgreSQL | Internal cluster traffic; CloudNativePG can enforce TLS | Cluster configuration |
In the Cloud, basebox configures all these paths; user access is exclusively via HTTPS on <your-organization>.basebox.ai, API access via HTTPS on aims.basebox.ai, and paths into your network (connectors, mail, directory) are TLS-protected – certificates of your target systems from a public CA or a private CA agreed with basebox (Network connectivity).
At rest
| Layer | Status | Who is responsible |
|---|---|---|
| Application (database fields, files) | Not implemented – the application stores plaintext in PostgreSQL and on the media volume (Infrastructure policy, Safety notice) | basebox (planned) |
| Credentials | Passwords of local accounts as hashes in Keycloak; per-user connector credentials stored write-only, never in logs; target system API keys of organization-wide connectors in the configuration database | basebox |
| Kubernetes Secrets | In etcd; encryption of etcd at rest is a cluster setting | Server: Platform Operator · Cloud: basebox |
| Storage layer (disks, storage class, volumes) | Encrypted disks or an encrypting storage class – the effective control today | Server: Platform Operator · Cloud: basebox |
| Backups | Dumps and object storage targets must themselves be encrypted and access-restricted | Operator |
For the review this means: a basebox installation meets the requirement "encryption at rest" via the storage layer, not via the application. On a server, document which disks are encrypted (for example LUKS on the volumes of databases and media) and where the keys are kept. In addition, the safety notice recommends not entering sensitive data unprotected into prompts or knowledge sources whose confidentiality depends solely on storage encryption.
Key management
| Key / secret | Location | Rotation |
|---|---|---|
| TLS certificate of the ingress | Kubernetes Secret; renewed automatically with cert-manager |
Automatically or when your own certificate expires |
Database passwords (*-database) |
Kubernetes Secrets, managed by CloudNativePG | Cluster procedure |
| Keycloak admin, basebox admin | Kubernetes Secrets (keycloak-admin-secret, basebox-admin-secret) |
Per your password process |
| Inference API key | Secret (external-inference-api or similar), via secretKeyRef into AISRV – never in values files |
On change, update the secret and restart AISRV |
| Registry access for images/charts | Secret / Helm registry login | On change |
| API keys of users/developers | Generated in the application, revocable | By the administrator (API keys) |
| Per-user connector credentials | Application, write-only | By the user; revocation in the target system takes effect immediately |
Whoever may read Kubernetes Secrets can read all platform secrets – restrict that via RBAC to the Platform Operator. Under operation by basebox, this role is part of the maintenance access (Remote maintenance).
What you can check
kubectl -n basebox get ingress # TLS hosts and secret
kubectl -n basebox get secret <tls-secret> -o jsonpath='{.type}' # kubernetes.io/tls
curl -vI https://<basebox-host>/ 2>&1 | grep -i 'TLS\|issuer'
kubectl -n basebox get deploy aisrv -o yaml | grep -A2 AISRV_LLM_URL # https for an external endpoint
At the storage layer: lsblk/cryptsetup status on the node, or the encryption property of your storage class.
Frequently asked questions
Is basebox "end-to-end encrypted"? No, and an application that passes content to a language model cannot be in principle: the platform must process prompts in plaintext. Protection comes from transport encryption, storage encryption, access control and – on Server – the boundary of the customer network.
When will encryption at rest arrive in the application? It is listed as planned in the infrastructure policy. This documentation names no date; ask support@basebox.ai.
Is storage encryption sufficient for patient data? That is a question of your protection needs and your supervisory authority. Technically, combined with access control, a dedicated server and short retention, it is a common control; the assessment lies with you as controller.
Next step: Retention