Learn MicroCloud - Snap Security & Confinement

#Introduction

So far we've focused on functionality — clusters, storage, networking. But a cloud serving production demands security. In episode 13 we cover the security foundation of MicroCloud that has been lurking behind every snap install: the snap confinement model and the operational practices that come with it.

An analogy: every MicroCloud component is like an employee working in a locked room (strict confinement). It can only access what's allowed — certain desks, files, and doors. An upgrade is like replacing the room's equipment: if the new equipment is broken, the system automatically restores the old equipment (rollback) without waking anyone up. This is security and resilience fused into the distribution model.

#The Snap Security Model

#Strict Confinement

All MicroCloud components — lxd, microceph, microovn, microcloud — run under strict confinement. This means:

• Each snap runs in a sandbox with its own filesystem namespace.
• Access to host resources is restricted by snap interfaces (AppArmor + seccomp underneath).
• A snap can only touch what's allowed via its declared slots/plugs.

snap info lxd | grep confinement
snap info microceph | grep confinement
snap info microovn | grep confinement

All must show strict. With this confinement, compromising one component doesn't automatically grant full host access — the impact is bounded by the sandbox.

#AppArmor and seccomp

Two kernel mechanisms work behind strict confinement:

• AppArmor: restricts the files and network paths a snap may touch.
• seccomp: restricts the syscalls a snap may invoke.

aa-status | grep snap.lxd

AppArmor profiles are applied automatically when a snap runs. This is the layer that makes strict confinement truly "strict", not just a label.

#Transactional Updates and Rollback

#Safe Updates

Snap updates components with a transactional model:

1. The new snap is downloaded and installed into a separate snapshot.
2. The service is switched to the new version atomically.
3. If it fails (broken config, service crash), the snap automatically rolls back to the previous version.

snap list lxd microceph microovn microcloud
snap refresh --list

#Keeping Versions from Changing Suddenly

Automatic updates can surprise you in production. Hold refresh to control when upgrades happen:

sudo snap refresh --hold lxd microceph microovn microcloud

sudo snap refresh --unhold lxd microceph microovn microcloud
sudo snap refresh lxd

#Manual Rollback

If a new version misbehaves after a refresh, return to the previous revision:

sudo snap revert lxd

snap revert moves the snap to the old revision still stored — the same mechanism as automatic rollback, but triggered manually.

#Snap Security Best Practices

#Don't Install Components Outside of Snaps

MicroCloud is designed as a single snap ecosystem released and tested together. Don't install components outside of snaps — for example Ceph via APT, or LXD from manual binaries — because:

• Versions won't match the MicroCloud snap.
• Transactional updates and automatic rollback are lost.
• Confinement doesn't apply, widening the attack surface.

If a feature isn't available in the snap, that's more often intentional (a design decision) than a shortcoming — ask on the forum before bypassing it.

#Review Snap Interfaces

A snap declares the access it needs via interfaces. Regularly review who has access to what:

snap connections lxd
snap connections microceph
snap connections microovn

Pay attention to important interfaces like firewall-control, network, and storage — make sure there are no strange connections you didn't intend.

#Operational Principles

• Use the stable channel and hold refresh in production.
• Watch for CVEs in snap releases — address them with planned refreshes.
• Restrict snap admin access (sudo snap and the lxd group) to trusted people.
• Use confinement for compartmentalization: don't run other admin tools inside snap environments.

#Common Pitfalls

• Copying Ceph binaries outside snaps: version conflicts, microceph config doesn't recognize them, and more dangerously — no confinement.
• Auto-refresh breaking production: the fix is snap refresh --hold and a maintenance window.
• Upgrading nodes one by one without an order: version consistency between nodes matters more than speed; use the same order and verify each node.
• Ignoring interface reviews: loose interfaces (e.g., system-files) increase risk if a snap is compromised.

#Closing

Key takeaways:

• All MicroCloud components run under strict confinement (AppArmor + seccomp).
• Snap updates are transactional with automatic rollback; snap revert for manual rollback.
• Hold auto-refresh in production and update all nodes together.
• Don't install components outside of snaps — versions, updates, and confinement will break.
• Review snap connections regularly.

In the next episode, we'll cover network isolation & TLS — separating the underlay (storage/OVN) from client access, VLAN/firewall per segment, LXD remotes via lxc remote add with certificates, and encrypted admin access. Network security is the next frontline!