Linux on Backend Engineering Strategy Tools

Linux Identity Management — FreeIPA and SSSD

Mon, 01 Jan 2024 00:00:00 +0000

Managing user accounts across many Linux machines by hand — creating the same user on every host, syncing passwords, maintaining sudo rules — breaks down fast. FreeIPA provides centralised identity management: one place to define users, groups, sudo rules, host policies, and SSH keys. SSSD is the daemon that runs on each Linux machine and connects it to FreeIPA (or any LDAP/Kerberos provider), making those central definitions available locally.

FreeIPA

An integrated identity management solution from Red Hat, combining LDAP (389 Directory Server), Kerberos, DNS, a certificate authority, and a web UI into a single deployable stack. Users, groups, sudo rules, HBAC (host-based access control) rules, and SSH public keys are all managed centrally and enforced on enrolled hosts. FreeIPA is the open source upstream of Red Hat Identity Management (IdM).

Install on RHEL/Rocky/AlmaLinux:

dnf install freeipa-server
ipa-server-install --domain=example.com --realm=EXAMPLE.COM

Once the server is running, enroll a client host:

dnf install freeipa-client
ipa-client-install --server=ipa.example.com --domain=example.com

After enrollment, users defined in FreeIPA can log into the host with Kerberos SSO — no separate account needed on the machine.

SSSD

The System Security Services Daemon. SSSD runs on each Linux host and mediates all identity lookups — NSS (name service switch) queries for users and groups, PAM authentication, sudo rule lookups. It caches responses locally so logins still work when the identity server is temporarily unreachable, and it handles the Kerberos ticket lifecycle transparently.

SSSD is not FreeIPA-specific. It supports:

FreeIPA (the natural pairing)
Active Directory (via the ad provider — direct AD integration without Samba)
Generic LDAP and Kerberos

The ipa-client-install command configures SSSD automatically when enrolling a FreeIPA client. For AD integration, the configuration is similar but uses the ad provider:

[domain/example.com]
id_provider = ad
auth_provider = ad
access_provider = ad
ad_domain = example.com
krb5_realm = EXAMPLE.COM

The pairing

FreeIPA and SSSD are complementary halves of the same solution. FreeIPA is the authoritative store — where you create and manage identities. SSSD is the enforcer on each host — it translates FreeIPA’s policies into local authentication decisions, caches them for resilience, and keeps Kerberos tickets current. Neither replaces the other; together they give you centralised identity management with no single point of failure for login availability.

Resources

LUKS — Linux Disk Encryption

Mon, 01 Jan 2024 00:00:00 +0000

LUKS (Linux Unified Key Setup) is the standard for full-disk encryption on Linux. It uses dm-crypt in the kernel to encrypt block devices transparently — the filesystem sits on top of an encrypted layer, and the encryption happens below it. The LUKS header stores the encrypted key material and metadata, supporting up to eight independent key slots (passphrases or keyfiles) that all unlock the same volume.

Setup

# Encrypt a device (destroys existing data)
cryptsetup luksFormat /dev/sdb

# Open the encrypted device, exposing it as a plaintext mapper device
cryptsetup luksOpen /dev/sdb data-encrypted

# Format and use the plaintext device normally
mkfs.ext4 /dev/mapper/data-encrypted
mount /dev/mapper/data-encrypted /mnt/data

# Close when done
umount /mnt/data
cryptsetup luksClose data-encrypted

Key slots

LUKS supports multiple passphrases or keyfiles — useful for adding a recovery key alongside an operational passphrase:

# Add a second key slot (e.g. a recovery keyfile)
cryptsetup luksAddKey /dev/sdb /path/to/recovery.key

# Remove a key slot
cryptsetup luksRemoveKey /dev/sdb

# List key slot usage
cryptsetup luksDump /dev/sdb

Auto-unlock at boot

For encrypted root or data partitions that should unlock automatically on boot, add the device to /etc/crypttab with a keyfile path:

data-encrypted /dev/sdb /etc/keys/data.key luks

Then add the plaintext device to /etc/fstab as normal. On servers, the keyfile is stored on a separate volume or fetched from a secrets manager (Vault, Tang/Clevis for network-bound disk encryption).

Use in Kubernetes

Node-level disk encryption with LUKS protects data at rest on Kubernetes worker nodes — persistent volume data stored on the node’s disks is encrypted before it leaves the kernel. Talos Linux enables LUKS encryption for its state and ephemeral partitions by default.

Resources

LVM — Logical Volume Manager

Mon, 01 Jan 2024 00:00:00 +0000

LVM adds a virtualisation layer between physical disks and filesystems. Instead of formatting a disk partition directly, you assemble physical volumes into a volume group and carve logical volumes out of the pool. This makes resizing, snapshots, and spanning volumes across multiple disks straightforward operations rather than destructive partition table surgery.

Layers

Layer	Description
Physical Volume (PV)	A disk or partition initialised for LVM use (`pvcreate`)
Volume Group (VG)	A pool of storage assembled from one or more PVs
Logical Volume (LV)	A virtual partition carved from a VG, formatted and mounted like a regular disk

# Initialise two disks as PVs
pvcreate /dev/sdb /dev/sdc

# Create a VG from both
vgcreate data-vg /dev/sdb /dev/sdc

# Create an LV using all available space
lvcreate -l 100%FREE -n data-lv data-vg

# Format and mount
mkfs.ext4 /dev/data-vg/data-lv
mount /dev/data-vg/data-lv /mnt/data

Resizing

The practical benefit over raw partitions: extend a logical volume online without unmounting:

# Extend the LV by 50GB
lvextend -L +50G /dev/data-vg/data-lv

# Grow the filesystem to fill the new space
resize2fs /dev/data-vg/data-lv

Snapshots

LVM supports copy-on-write snapshots. A snapshot captures the LV state at a point in time and stores only the blocks that change afterwards:

lvcreate -L 10G -s -n data-snap /dev/data-vg/data-lv

Used for consistent backups of live filesystems — snapshot, back up the snapshot, remove it. Rook/Ceph and cloud providers use similar snapshot semantics at the storage layer.

Resources

Virtualization — KVM and KubeVirt

Mon, 01 Jan 2024 00:00:00 +0000

KVM is the Linux kernel’s native hypervisor. KubeVirt extends Kubernetes to run virtual machines using KVM under the hood. They are the same virtualization layer at different levels of abstraction — KVM on bare metal, KubeVirt in a Kubernetes cluster.

KVM

Kernel-based Virtual Machine. KVM turns the Linux kernel into a hypervisor using hardware virtualization extensions (Intel VT-x, AMD-V). Virtual machines run as regular Linux processes backed by QEMU for device emulation. Managed via libvirt and its CLI tools (virsh, virt-install) or the virt-manager GUI.

# Create a VM from an ISO
virt-install \
 --name ubuntu-vm \
 --ram 4096 \
 --vcpus 2 \
 --disk path=/var/lib/libvirt/images/ubuntu.qcow2,size=40 \
 --cdrom /tmp/ubuntu.iso \
 --os-variant ubuntu22.04

# List running VMs
virsh list

# Start/stop
virsh start ubuntu-vm
virsh shutdown ubuntu-vm

# Connect to console
virsh console ubuntu-vm

KVM gives near-native performance for CPU-bound workloads. Network and disk I/O use virtio drivers for efficient paravirtualised I/O. Live migration moves a running VM between hosts without downtime if shared storage is available.

KubeVirt

KubeVirt adds VirtualMachine and VirtualMachineInstance CRDs to Kubernetes. VMs are defined as Kubernetes resources, scheduled by the Kubernetes scheduler, and managed alongside containers. Under the hood, each VM runs as a pod containing a QEMU-KVM process.

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
 name: ubuntu-vm
spec:
 running: true
 template:
 spec:
 domain:
 devices:
 disks:
 - name: rootdisk
 disk:
 bus: virtio
 resources:
 requests:
 memory: 4Gi
 cpu: "2"
 volumes:
 - name: rootdisk
 containerDisk:
 image: kubevirt/fedora-cloud-container-disk-demo

The virtctl CLI complements kubectl for VM-specific operations:

virtctl start ubuntu-vm
virtctl stop ubuntu-vm
virtctl console ubuntu-vm # serial console
virtctl ssh ubuntu-vm # SSH via the Kubernetes API
virtctl migrate ubuntu-vm # live migrate to another node

CDI — Containerized Data Importer

KubeVirt is typically paired with CDI, which imports VM disk images from URLs, container registries, or PVCs into DataVolume resources that VMs can boot from. CDI handles the data flow; the VM definition just references the DataVolume.

Why VMs in Kubernetes

Some workloads can’t be containerised — legacy applications expecting a full OS, Windows workloads, software with kernel module requirements. KubeVirt lets those workloads live in the same cluster as containers, managed with the same tooling, subject to the same scheduling and networking policies.