↓ Skip to main content
Le Site de François
  1. Index/

RHCOS (Red Hat Enterprise Linux CoreOS)

Linux Security Openshift Immutable Selinux Luks Tpm Boot

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.

Provisioning and first-boot security in RHCOS is handled by Ignition: a first-boot provisioning tool that runs in the initramfs before any systemd unit, reads a JSON configuration document (the Ignition config) delivered via userdata, kernel argument, or a URL, and applies an ordered set of filesystem operations, file writes, and systemd unit enablements before handing off to systemd. The Ignition config is the canonical bootstrap artifact — it configures network interfaces, writes SSH authorised keys, installs certificates, and optionally configures disk encryption before any user data is written. RHCOS disk encryption is not enabled by default and must be explicitly opted into via the diskEncryption stanza in the OpenShift install-config: tpm2 mode seals the LUKS2 volume key to the node’s TPM2 chip using a Clevis tpm2 pin (with PCR 7 for Secure Boot state), tang mode binds it to a Tang server using NBDE/Clevis, and combining both — with a Clevis SSS threshold-2 policy requiring both the TPM PCR measurement and Tang server reachability — is the recommended pattern for bare-metal deployments requiring the strongest protection. The cipher used is AES-256-XTS (or AES-256-CBC in FIPS mode). When encryption is configured, it is applied before the first systemd unit runs — all data written to the root disk from the very first journal entry onwards is encrypted, with no unencrypted window during installation. Secure Boot is supported and recommended on bare-metal: RHCOS ships a shim-signed EFI binary chain rooted in the Microsoft CA, with GRUB as the bootloader (RHCOS does not yet support UKI-based boot) measuring boot components into TPM PCRs via GRUB’s TPM module, enabling the TPM2 PCR 7 Clevis binding to reflect the Secure Boot policy state that was active when the disk was sealed.

Runtime security controls in RHCOS are non-negotiable by design. SELinux is always enforcing — disabling it is explicitly unsupported, and a node with SELinux disabled must be re-provisioned rather than reconfigured before it can rejoin a production cluster. The targeted policy with MCS category separation confines every container process to a unique label pair and the sVirt model (via libvirt on KVM-backed nodes) extends this to VM processes. cgroups v2 is the default resource controller since OpenShift 4.14, enabling the QoS-based eviction and memory pressure handling that cgroupv2 provides. seccomp profiles are applied to containers by the container runtime (CRI-O, which replaced Docker in OpenShift 4.x) using the RuntimeDefault profile mandated by the PSA Restricted policy; SCCs provide the OpenShift-specific pod security layer on top of PSA, with the restricted-v2 SCC as the default for all authenticated users. The CRI-O container runtime implements only the features required by Kubernetes, deliberately excluding the broader feature surface of daemon-oriented container engines — reducing the attack surface compared to a general-purpose container runtime. FIPS 140-3 mode can be enabled cluster-wide at install time (fips: true in install-config.yaml); this switches the kernel and all cryptographic libraries to FIPS-approved algorithms (AES-256-CBC for LUKS, HMAC-SHA-256 for integrity, RSA-2048 minimum for TLS), and once enabled cannot be disabled without re-provisioning. The MCO manages day-2 security hardening through MachineConfig objects: kernel arguments (audit=1, slub_debug), sysctl settings via MachineConfig with kernel-devel extensions, custom SELinux policy modules via MachineConfig file drops into /etc/selinux/targeted/, and AIDE configuration — all applied uniformly across node pools through the same GitOps-friendly MachineConfig API, making RHCOS security posture reproducible, auditable, and version-controlled in the same repository as the workloads it runs.

Related

KVM/QEMU

Virtualization Linux Kvm Qemu Security Libvirt Openshift Seccomp Selinux
KVM (Kernel-based Virtual Machine) and QEMU (Quick Emulator) solve different halves of the same problem and are almost always used together. KVM is a Linux kernel module that turns the kernel into a hypervisor: with Intel VT-x or AMD-V, guest CPUs run on real hardware at near-native speed and guest memory is managed through extended page tables. KVM has no device model of its own — no disk, network, or firmware emulation. QEMU supplies that in userspace (virtio, USB, VGA, ACPI) and controls KVM by issuing ioctl calls on /dev/kvm — creating VMs, mapping memory, running vCPUs via KVM_RUN — while QMP exposes external management over a Unix socket. libvirt, originally from Red Hat, sits above both: it translates domain XML into QEMU command lines and lifecycle operations. The stack is the default on Linux: RHEL ships qemu-kvm, OpenShift Virtualization runs KubeVirt (virt-launcher → libvirt → QEMU), and OpenShift Sandboxed Containers uses Kata Containers with the same hypervisor to isolate pods in micro-VMs.

Measured Boot

Security Boot Tpm Attestation Linux Firmware Uefi
Measured Boot is a boot process architecture in which each component in the boot chain — firmware, bootloader, kernel, initrd, kernel command line — is cryptographically hashed and that hash is recorded into a TPM Platform Configuration Register (PCR) before the component executes. The critical distinction from Secure Boot is in what each mechanism provides: Secure Boot is an enforcement mechanism that prevents unauthorised components from running at all; Measured Boot is a recording mechanism that creates a tamper-evident log of exactly what did run, without necessarily preventing anything. The two are complementary and typically deployed together — Secure Boot enforces a policy at boot time, Measured Boot produces the evidence that the policy was enforced as claimed. A system can have Measured Boot without Secure Boot (it records everything that ran, even unsigned components), but Secure Boot without Measured Boot provides enforcement with no attestable evidence of what was enforced.

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

Security Encryption Storage Linux Luks Boot Rhel
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.