LXD security

To recreate a "Cloud-Style" secure environment using LXD on-premise, you have to move away from the idea of being a "System Admin" and start acting like a "Service Provider."

In a standard setup, you sudo into everything. In a high-security LXD setup, you use Project Isolation, Restricted Roles, and Hardware-Backed Encryption.

1. Project Isolation (The Virtual Private Cloud)

Don't just run containers in the "default" project. Projects in LXD act like AWS Accounts or Azure Subscriptions. They have their own networks, storage volumes, and—crucially—their own security policies.

# Create a secure project
lxc project create secure-zone -c features.networks=true -c features.images=true

# Switch to it
lxc project switch secure-zone

2. Restrict the "Admin" (RBAC)

To prevent a rogue local admin (or yourself by mistake) from having "God Mode" over every container, you should use Canonical RBAC (Role-Based Access Control) or integration with OpenID Connect.

By integrating LXD with an identity provider (like Keycloak or Authelia), you can ensure that even if someone has a login to the physical host, they don't have the "LXD API" permissions to peek into a specific project's containers without an audited login.

3. Encryption at Rest (The Storage Layer)

In AWS, the EBS volumes are encrypted. In LXD, you should use ZFS or LVM with LUKS.

The Goal: If someone steals the physical hard drives from your server, they see nothing.
The Setup: Encrypt the entire partition using LUKS before assigning it to the LXD Storage Pool.

# Example: Creating an encrypted ZFS pool for LXD
cryptsetup luksFormat /dev/sdb
cryptsetup open /dev/sdb crypt_storage
lxc storage create encrypted-pool zfs source=/dev/mapper/crypt_storage

4. Shielded Containers (The "Nitro" Equivalent)

LXD allows you to run Virtual Machines (VMs) instead of just containers. While containers share the host kernel (easier for a rogue root user to "escape"), LXD VMs use a separate kernel and hardware virtualization (QEMU/KVM).

For your most sensitive data, use an LXD VM with vTPM (Virtual Trusted Platform Module) enabled:

lxc launch ubuntu:24.04 my-secure-vm --vm -c limits.cpu=2 -c security.agent=true

5. The "No-Sudo" Architecture (The API Approach)

The biggest risk in an on-premise setup is someone running sudo lxc exec container bash.

To mitigate this: 1. Disable root SSH: Never allow root login on the host. 2. Use the LXD Brink/Candid: Force all container access through a remote API call that requires a multi-factor authentication (MFA) token, rather than direct local socket access. 3. Kernel Hardening: Use AppArmor and Seccomp (enabled by default in LXD) to prevent containers from making sensitive system calls to the host kernel.

Summary Checklist for a "Private Cloud"

Feature	Local LXD Setup
Identity	Integrate with OIDC/Keycloak (No local passwords).
Storage	LUKS-encrypted ZFS or LVM pools.
Isolation	Use LXD Projects to silo different departments/apps.
Runtime	Use VMs (`--vm`) for high-security, Containers for dev.
Auditing	Forward LXD logs to a separate, write-only syslog server.