Luks on Le Site de François

initramfs (initial RAM filesystem)

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

initramfs (initial RAM filesystem) is the temporary root filesystem the Linux kernel mounts immediately after loading itself and before switching to the machine’s real root. The bootloader — GRUB, systemd-boot, or firmware loading a UKI — passes a compressed cpio image (historically called an initrd, though modern Linux always unpacks it as an initramfs into tmpfs, not a separate ramdisk block device). The kernel extracts this archive into an in-memory tree, executes /init as pid 1, and that early userspace environment is responsible for everything the bare kernel cannot yet do: loading storage and filesystem kernel modules, bringing up networking, discovering and unlocking LUKS volumes, activating LVM or multipath devices, mounting the true root partition, and finally calling switch_root (or pivot_root) to hand control to the installed system’s init — typically systemd on current distributions. If the initramfs fails, the boot stops before userspace on the real root ever starts; if it succeeds, it is discarded and its memory reclaimed once the pivot completes.

NBDE / Clevis / Tang (Network-Bound Disk Encryption)

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

NBDE (Network-Bound Disk Encryption) is an approach to automatic LUKS disk unlocking that binds the volume key not to hardware state (a TPM PCR measurement) but to network presence: a LUKS-encrypted volume unlocks automatically at boot if and only if the machine can reach a designated Tang server on a trusted network. Remove the machine from that network — because it was stolen, because a data centre drive was pulled, because someone exfiltrated the hardware — and the volume key becomes unrecoverable without a fallback passphrase. The threat model is therefore complementary to TPM-based unlocking: TPM sealing asks “is this the right software stack?” and locks the key to a specific platform measurement; NBDE asks “is this machine on the trusted network?” and locks the key to network presence. Neither addresses both threat classes alone, which is why the two are routinely combined — and why RHEL formalises NBDE as a subcategory of the broader Policy-Based Decryption (PBD) framework that the Clevis pin system implements.

RHCOS (Red Hat Enterprise Linux CoreOS)

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

RHCOS (Red Hat Enterprise Linux CoreOS) is the operating system that runs on every OpenShift control plane and worker node. It is not a general-purpose Linux distribution — it is a purpose-built, immutable, container-optimised OS designed to run exclusively as a managed node in an OpenShift cluster. Its security posture is architecturally different from a hardened RHEL installation: rather than hardening a mutable system through configuration management, RHCOS makes the OS layer structurally resistant to modification by design. The root filesystem’s /usr tree is read-only (enforced at mount time by rpm-ostree and, in recent versions, by composefs over the OSTree object store), /etc and /var are writable but managed exclusively by the Machine Config Operator (MCO), and no package manager is available at runtime for ad-hoc software installation. An operator who wants to change any node-level configuration — kernel arguments, sysctl settings, systemd units, certificates, kubelet configuration — creates a MachineConfig object in the OpenShift API; the MCO renders it into an Ignition config, applies it to the target MachineConfigPool (master, worker, or custom), and drains and reboots the affected nodes in a rolling fashion. Direct SSH access to nodes for configuration changes is explicitly unsupported and actively discouraged — oc debug node/<name> is the supported emergency access path, dropping into a privileged container on the node’s host namespaces under audit.

Storage Encryption

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

Storage encryption is not a single feature but a four-layer decision that must be made independently, because each layer addresses a different adversary and a different failure mode. Layer 1 — disk/OSD at-rest encryption protects against physical media theft: a decommissioned OSD or stolen drive is unreadable without the key. Layer 2 — cluster-internal wire encryption protects against a network-layer attacker who can observe traffic between storage nodes: OSDs, monitors, and clients on the cluster network. Layer 3 — PV/volume-level encryption protects against a storage operator or another tenant reading a workload’s data through the storage system itself — the threat model where the storage cluster is itself potentially untrusted or multi-tenant. Layer 4 — object storage server-side encryption provides per-object key management for S3-compatible workloads, enabling customer-managed keys (CMK) and per-tenant key isolation in object stores. These layers are independent and composable: enabling Layer 1 without Layer 2 protects against physical theft but not a network interceptor; enabling Layer 3 without Layer 1 protects against the storage operator but not physical media extraction. A complete encryption posture addresses all four explicitly, even if some layers are deliberately left disabled with a documented rationale.