Skip to main content

Encrypted local volumes

Lium can store the pod's local volume at /root as ciphertext on the provider's disk. Inside the running pod, it looks like a normal filesystem.

What it protects​

Encryption covers data at rest. A leftover volume, a disk image, or a drive that leaves the datacentre is unreadable by itself.

It does not protect a running pod. A provider with host access can read /root while your pod is up, inspect its memory, or capture the key. If the provider must never see your workload, rent a CVM-enabled machine instead. Full model: Pod security.

Using it​

On the Create Pod page, Encrypt local volume appears for official templates that support it. Encryption is on by default.

The API, SDK, and CLI request encryption by default too. To turn it off:

  • API: "enable_volume_encryption": false in the rent request.
  • SDK: Lium.up(..., enable_volume_encryption=False).
  • CLI: lium up --no-volume-encryption.

The template decides whether the UI shows the option. At deploy time, Lium checks the template's Docker image. If the image does not support encryption, the pod starts with a plain volume and the rental goes ahead.

Tradeoffs​

  • Disk is slower. On an A6000 node with an EPYC 7763, a mixed 70/30 random read/write test went from 1008 to 625 MiB/s read and 435 to 271 MiB/s write. That is roughly 38% less throughput. Your numbers depend on the host and workload.
  • Backups need a running pod. Backups and restores of an encrypted volume only work while the pod is up.
  • Nested Docker cannot bind-mount it. On a Docker-in-Docker template, docker run -v /root/data:/data … fails with error mounting "/root/data" to rootfs … change mount propagation through procfd … no such file or directory — the encrypted mount cannot be propagated into a child container. Bind-mount from /workspace instead (-v /workspace/data:/data); that path is a plain overlay and works on every node.

Status on the pod page​

After deploy, Volume encryption shows what actually happened:

  • Enabled: /root is encrypted.
  • Unavailable: the image did not support encryption, so the pod got a plain volume.
  • Disabled: encryption was turned off in the request.
  • Setup failed: the image supported encryption, but the encrypted mount did not come up.

If SSH suddenly asks for a password​

A pod that accepted your key and then starts prompting for a password has usually lost its plaintext mount. The provider's host rebooted and Docker restarted the container on its own; that path does not mount the encrypted volume, so inside the container /root is the image's empty, unreadable directory — no authorized_keys, and sshd falls back to asking for a password. Adding another key from the pod page changes nothing, because there is nowhere to write it. The pod page still shows RUNNING and billing continues, because the container itself is up.

Your data is intact: the ciphertext is still on the volume, only unmounted.

Fix: Reboot the pod from the pod page, or run lium reboot <pod>. A reboot recreates the container and mounts the volume again; your keys work as before. If the pod was unreachable for a while, open a support ticket for the downtime.

For agents and automation

The volume uses gocryptfs. The Docker volume holds ciphertext, and the decrypted view is mounted at /root. An image qualifies by shipping gocryptfs and carrying the lium.volume_encryption.enable=1 Docker label. Lium derives a passphrase per pod and hands it to the container at mount time. The passphrase is never written to the volume.