Learn MicroCloud - Encryption & Data Protection

#Introduction

Network isolation and TLS (episode 14) protect data in motion. But there's a moment that can't be avoided: data at rest on disks — and disks can be stolen, discarded, or handed over by mistake. In episode 15 we close this gap with encryption at rest, while also covering the trust mechanism when joining and audit logs for compliance.

An analogy: TLS is an armed courier delivering documents between cities. Encryption at rest is the locked safe where documents are stored in the warehouse. However well the courier is guarded, if the safe isn't locked, anyone who steals the warehouse reads all the documents. Proactive trust and audit logs are the warehouse's guestbook and CCTV: they know who entered, when, and what they did.

#Ceph Disk Encryption (LUKS)

#Encryption During Init

MicroCeph supports OSD encryption with LUKS (Linux Unified Key Setup). When microcloud init or microcloud join asks you to select disks, you're offered the encryption option:

Encryption prompt during init/join

Select disks for Ceph storage:
  /dev/sdb  500G  (empty)
Encrypt disk /dev/sdb with LUKS? (yes/no) [default=no]

Choose yes to encrypt the OSD. MicroCeph creates a LUKS container on the disk, stores the key securely, and all data on that OSD is written in an encrypted state.

#Verifying an Encrypted OSD

Check OSD encryption status

sudo microceph disk list
sudo lsblk -o NAME,SIZE,TYPE,FSTYPE

An encrypted OSD will show the crypt type in lsblk — proof that LUKS is active at the block layer.

Tip

Encryption must be decided when a disk is added (init/join/microceph disk add) — not after data is flowing. Encrypting a disk that already holds data requires a complex data migration. Plan for it from the start if your cluster will handle sensitive data.

#Encryption at Rest: What It Protects

With LUKS on every OSD:

Ceph data (instance volumes, pools, snapshots) is encrypted at rest.
A stolen/discarded disk is unreadable without the key.
A small performance overhead (a few percent, depending on CPU) — a reasonable trade-off for sensitive data.

Before/after encryption comparison

tanpa LUKS:  disk ──► data Ceph polos (readable siapa pun)
dengan LUKS: disk ──► [LUKS container] ──► data Ceph (terenkripsi)

#Proactive Trust When Joining

#The Problem with Manual Trust

Without proactive trust, every time a new node joins, the admin must manually approve that peer's certificate. On a large fleet with many nodes, this hampers automation and risks mis-confirmation.

#Proactive Trust (init 2.1+)

Since MicroCloud 2.1, you can mark trusted nodes before the join begins. During microcloud init or before adding a node, register the fingerprints of allowed nodes:

sudo microcloud cluster trust add --name node-d

With proactive trust, registered nodes can join without an approval prompt — speeding up automation and reducing human error. Nodes outside the list are still rejected.

Warning

Proactive trust is a double-edged sword: convenient for automation, but if a node's certificate leaks, an attacker could exploit that trust. Limit the trust list to nodes you truly control, and remove them when the nodes are no longer in use.

#Revoking Trust

Revoke a member's trust

sudo microcloud cluster trust remove node-d

#Audit Logs for Compliance

#LXD Logs

LXD records all operations to its audit log — who did what via the API:

LXD audit logs

sudo snap logs lxd -n 200
journalctl -u snap.lxd.daemon -n 200

The logs record lxc commands, the remotes that accessed the API, and the operations executed — valuable material for investigations and compliance.

#Snap and Cluster Logs

snap logs microcloud — orchestrator activity.
snap logs microceph — storage activity (OSD, recovery).
snap logs microovn — networking activity.

Example: microcloud logs

sudo snap logs microcloud -n 100

#Recommended Audit Policy

Centralize logs: ship logs to an external system (Loki, syslog) so they survive node loss.
Clear retention: keep logs per your organization's compliance needs (e.g., 90-365 days).
Log monitoring: alert on suspicious patterns — new remotes, lxc config trust changes, or repeated OSD down events.

#End-to-End Data Protection

A summary of your data protection layers so far:

At rest: LUKS on Ceph OSDs (this episode).
In transit: TLS for the admin API (episode 14) + isolated network segments.
Replication: the Ceph replication factor maintains availability (episode 6).
Snapshots/backups: recovery from mistakes (episode 10).
Trust: certificates + proactive trust restrict who can enter the cluster.

#Common Pitfalls

Encrypting outside LUKS (e.g., application-level encryption): can conflict with Ceph features (compression, tiering) — use the mechanism MicroCeph provides.
Losing the LUKS key: MicroCeph manages keys internally; don't delete the keyring or discard a crypt disk without a procedure.
Trust too loose: register proactive trust only for nodes that actually exist.
No log centralization: if a node dies, its audit logs die with it — ship them outside the cluster.

#Closing

Key takeaways:

OSD encryption with LUKS is chosen when a disk is added — protect data at rest from the start.
Proactive trust (init 2.1+) allows joining without a manual prompt, but keep its use restricted.
Audit logs from LXD and the snaps are the trail for compliance and investigations.
Data protection is a combination: encryption + TLS + replication + backups + trust.
Plan encryption before production, not after.

In the next episode, we'll cover troubleshooting — microcloud status, snap logs microcloud, microceph status, microovn status, common cases like failed joins, small disks, underlay network, and clock skew, plus member recovery and service re-init. Every admin needs this toolkit!