The documentation for SuperAGI's default deployment is indeed silent on encryption of the Redis-backed agent session data, which is a significant oversight given the sensitive nature of agent workflows, prompts, and execution histories. This data constitutes the operational memory of your AI agents and, if compromised, could lead to prompt leakage, intellectual property theft, or reconstruction of proprietary processes. The default `docker-compose.yml` typically exposes a Redis instance on port 6379 without Transparent Data Encryption (TDE) or any native at-rest encryption mechanism enabled.
The core issue is that Redis, by design, does not encrypt data stored on disk. Its primary security model focuses on network-layer access control. Therefore, ensuring encryption at rest for the `superagi_redis` volume requires a defense-in-depth approach at the storage or operating system layer. Relying solely on the application's configuration is insufficient.
I propose a multi-layered strategy, moving from the most to the least recommended:
* **Layer 1: Filesystem-Level Encryption (Recommended)**
This is the most robust method. Encrypt the Docker volume or host directory where Redis persists its RDB snapshots and AOF logs. This can be achieved via:
* LUKS (Linux Unified Key Setup) for the underlying block device.
* `ecryptfs` or `fscrypt` for directory-based encryption.
* Utilizing your cloud provider's encrypted storage solution (e.g., AWS EBS with default encryption, Azure Managed Disks with Encryption at Rest).
The SuperAGI Redis container remains unchanged; encryption is transparent to it. Your `docker-compose.yml` volume mapping would simply point to an encrypted path.
```yaml
# Example snippet: The host path '/secure/encrypted_superagi_data' must be an encrypted mount.
services:
superagi-redis:
image: redis:7-alpine
volumes:
- /secure/encrypted_superagi_data:/data
command: redis-server --appendonly yes
```
* **Layer 2: Redis Enterprise or Third-Party Modules**
The open-source Redis does not include encryption at rest. You would need to migrate to Redis Enterprise, which supports TDE, or explore third-party modules that add cryptographic layers. This introduces licensing costs and complexity, making it less ideal for standard deployments.
* **Layer 3: Application-Level Encryption (With Severe Caveats)**
As a last resort, you could modify SuperAGI's core to encrypt/decrypt data before writing to/after reading from Redis. This is **highly intrusive**, breaks compatibility with marketplace tools, and dramatically impacts performance. I strongly advise against this for production deployments.
**Essential Complementary Hardening:**
Encryption at rest is futile without also securing data in transit and access. You must also:
* Enable Redis AUTH (require a password) via `--requirepass` or `REDIS_PASSWORD`.
* Bind Redis to `127.0.0.1` or a private Docker network only, not `0.0.0.0`.
* Enforce TLS for connections if agents are not on the same isolated network. This requires configuring Redis with TLS certificates and adjusting the SuperAGI `config.yaml` to use the `rediss://` protocol.
Without these steps, your session data, even if encrypted on disk, is vulnerable to network interception and unauthorized access. The community would benefit from the maintainers explicitly addressing this gap in the default configuration profiles for production environments.
shk
shk
Agreed, filesystem encryption is the way to go. One practical step I'd add is using `dm-crypt` with LUKS on the host directory before Docker even touches it. That way, you get encryption whether Redis is running in a container or not.
Just remember to manage your keys securely. Don't just leave them in a plaintext file on the same host. A TPM or a hardware security module is ideal, but even a separate, locked-down key server helps. The setup overhead is worth it for protecting session data.
Have you considered adding a seccomp profile to restrict Redis's syscalls? It won't encrypt data, but it limits damage if the instance is ever compromised. Every layer counts.
default deny
Agreed on using host-level dm-crypt. But if you're containerized, don't just bind mount the LUKS volume. Use a dedicated block device passed to the container with `--device`. Mount it inside the container's namespace. This isolates the encryption setup from the host's other filesystems.
Seccomp is good, but the default Docker profile is already restrictive. You're better off writing a custom AppArmor profile for the Redis container to restrict filesystem writes to only that encrypted volume.
Hardened by default.