Learn MicroCloud - Network Isolation & TLS

#Introduction

In episode 13 security came from the snap model. Now we secure the network — the layer connecting your cloud to the outside world. In episode 14 we cover network isolation: separating the storage/OVN underlay from client access, VLANs and per-segment firewalls, then securing admin access via TLS and certificates with lxc remote add.

An analogy: your cloud building (cluster) has many doors. Inter-node storage is like an internal corridor — only for employees (cluster nodes). Client access is like a public reception — outsiders may enter but under rules. Admin access is like a locked server room — only people with a key (certificate) may enter. This episode installs the right signposts, doors, and locks.

#Separating the Underlay from Client Access

#Three Traffic Flows in MicroCloud

Inside a MicroCloud cluster, there are three types of traffic to understand:

• Storage (Ceph): data replication between nodes — most latency-sensitive, heaviest.
• OVN overlay: inter-node instance traffic (Geneve tunnels).
• Client/management: user access to instances, and admin access to the LXD API.

Mixing all three in one open segment makes eavesdropping easier and raises risk. A good design separates them.

#Recommended Underlay Design

For production, separate them with NICs or VLANs:

NIC eth0  ──► VLAN 10  management + client access
NIC eth1  ──► VLAN 20  storage (Ceph replication)
NIC eth2  ──► VLAN 30  overlay OVN (tunnel antar-node)

If NICs are limited, at minimum two segments:

• eth0/VLAN management — including client access and the admin API.
• eth1/VLAN storage+overlay — heavy internal cluster traffic.

#Firewalls per Segment

With segment separation, apply a firewall per interface. Example rules with ufw on each node:

sudo ufw allow from 192.168.10.0/24 to any port 8443 proto tcp
sudo ufw deny 8443

sudo ufw allow from 192.168.20.0/24 to any port 6081 proto udp
sudo ufw deny 6081

The rules above allow the admin segment to reach the LXD API (8443) and the cluster subnet for OVN tunnels (6081), while denying everyone else.

#Admin Access via TLS

#LXD Remotes and Certificates

The LXD API is exposed over HTTPS (default port 8443) with certificates for authentication. Admins access the cluster from any machine via lxc remote add:

lxc remote add mycloud https://node-a:8443 --accept-certificate

When added, you must trust the cluster certificate (a fingerprint is shown) and the cluster must accept your client certificate:

lxc config trust add < client.crt

lxc remote list
lxc remote switch mycloud
lxc cluster list

#Encrypted Admin Access

Once the remote is set up, all interaction runs over TLS 1.3:

• The server identity is verified from the cluster certificate.
• The client identity is verified from the trusted certificate.
• Admin traffic (creating instances, reading status) is encrypted.

client ──(TLS 1.3)──► https://node-a:8443 ──► LXD cluster
  │                                          │
  └─ cert client (ditrust)  ◄────────── cert cluster (fingerprint)

#Advanced Authentication Options

Beyond certificates, LXD supports Candid/SSO for identity-based authentication, and RBAC for per-user access control. For flexibility without building an SSO, you can add multiple certificates with different scopes.

#Isolation Best Practices

• LXD API only on the admin segment: don't expose 8443 to the public/client network.
• Rotate certificates: when an admin leaves or a certificate leaks, remove it from lxc config trust and issue a new one.
• Instance access via the OVN network: let users reach instances through the managed OVN IP/NAT, not directly to the host.
• Audit connections: use lxc config trust list to know who has admin access.

lxc config trust list

lxc config trust remove <fingerprint>

#Common Pitfalls

• Remote fails due to a certificate: redo --accept-certificate and make sure the client certificate is trusted in the cluster.
• Firewall blocking nodes from each other: a classic symptom — a "healthy" cluster that's intermittent; verify the inter-node ports first before guessing.
• Exposing 8443 to the public: very risky; if unavoidable, wrap it in a VPN or a reverse proxy + RBAC.
• Mixing traffic without segregation: fine for a lab, not for production — a small segment investment prevents big incidents.

#Closing

Key takeaways:

• Separate storage/overlay traffic from client access — separate NICs or VLANs.
• Apply per-segment firewalls; don't block inter-node communication.
• The LXD API (8443) must only be reachable from the admin segment, over TLS.
• lxc remote add + trusted certificates give encrypted admin access from anywhere.
• Rotate and review certificates regularly (lxc config trust list).

In the next episode, we'll cover encryption & data protection — Ceph disk encryption during init with LUKS, encryption at rest for data, proactive trust when joining since init 2.1, and audit logs for compliance. Your data will be safe at rest and in motion!