I live in Grand Rapids, Michigan, with my wife and our two sons, and we get around by cargo bikes. Family is in mid Florida, so Kennedy Space Center has been a regular visit. The homelab is where I run the stack, in the open (https://andrew.dunn.dev/about/).
Before GitLab: modeling and simulation for the Department of Defense, working with several nation states and government agencies, and a brief stint in the space community with NASA on terramechanics. The photos: a Saturn V at Kennedy, the cargo bike mid-splash, a Mars rover test yard.
Now: GitLab, a globally distributed open source organization. I work with regulated industries and build tooling.
The thread through it is open source and Linux, from bare metal to large systems, mobile and compact data centers included. I stretch the basic stack a long way before admitting a cluster is needed; that is why one person at home could do what the next faces show, and why the room can too.
Two habits from that stack: I was an early Podman enthusiast, and I never turn off SELinux. Containers as the unit of an operating system felt like the next step, not a leap.

The trade is the entry arrow: work I used to do on a host moves into CI. "No CI reaches a running host: an operator runs bootc upgrade and reboots on that host's own timeline" (https://cairn.dunn.dev/architecture/running/).
Inside the CI box every stage is something the phone already had: an image built whole, a boot before the tag moves ("A gate that fails skips promote, and the last good image stays where it is", https://cairn.dunn.dev/architecture/pipeline/), and a sealed root checked on read (https://cairn.dunn.dev/architecture/sealing/).
The dotted row is who holds the keys: my key signs the boot image and the modules, the firmware trusts only it. Public halves are published at https://cairn.dunn.dev/keys/.
We come back to this exact map at the end with every stage ticked, so you can see where each piece landed.

Both lanes are a working update. Android writes the update to the slot that is not running: "Read from the current slot A/B partitions and write any data to the unused slot A/B partitions" (https://source.android.com/docs/core/ota/ab).
The new slot is marked good only after checks pass: "A user space daemon, update_verifier, should mark slot A as successful after some checks are made" (source.android.com A/B). Say "marked good", not "must". If it fails to boot, "the device will reboot back into the old partition and remains usable".
iPhone, iOS 15 and later: the system volume is sealed, and "the iOS and iPadOS bootloaders verify that the seal is intact and that it matches an Apple-signed value ... before allowing the device to start the kernel" (https://support.apple.com/guide/security/signed-system-volume-security-secd698747c9/web).
A failed check has the same shape in both lanes: Android falls back to the old slot; on iPhone "Mismatches at boot prompt the user to update the system software", and users "aren't allowed to turn off the protection".
Do not say the iPhone halts and asks for a reinstall (that sentence is about the Mac), and do not say the iPhone has two slots; no source.

Tested: Android marks a slot good only after checks pass, "update_verifier, should mark slot A as successful after some checks are made" (https://source.android.com/docs/core/ota/ab). In image mode a candidate boots in CI before the tag moves: "A gate that fails skips promote, and the last good image stays where it is" (https://cairn.dunn.dev/architecture/pipeline/).
Atomic: bootc is "Transactional, in-place operating system updates using OCI/Docker container images" (https://bootc.dev/bootc/). Before, I patched package by package on the live host.
Rolls back: the phone keeps the old slot bootable. On my hosts it is opt-in, a health gate that calls bootc rollback after a run of failed boots; upstream has no boot counting yet (https://bootc.dev/bootc/bootc-composefs.7.html).
Verified: iPhone checks the seal against an Apple-signed value before the kernel starts (https://support.apple.com/guide/security/signed-system-volume-security-secd698747c9/web). A sealed image carries the root digest in the signed boot image and verifies every file on read (https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/using_image_mode_for_rhel_to_build_deploy_and_manage_operating_systems/cryptographic-sealing-of-bootc-images-technology-preview). Before, a scan compared the host to a baseline after the fact.

The trade, stated plainly: everything I used to do on the host, I now do in the image build. Package set, kernel arguments, users, firewall zones, enabled services, drivers: all moved into the Containerfile (gitlab.com/dunn.dev/cairn/base, images/base/Containerfile).
Patching became a daily CI schedule that rebuilds only when its resolved inputs changed (cairn.dunn.dev, pipeline page). Before that rule, "An unchanged day cost 46 jobs and about two hours of runner time to reproduce the image already at :stable" (cairn.dunn.dev, pipeline page).
Drift changed shape: it shows up as a failed build, not a scan on a host. The manifest gate and policy diff compare the built image against committed references (gitlab.com/dunn.dev/cairn/base, CI manifest gate).
What stays on the host: pull and reboot. "No CI reaches a running host: an operator runs bootc upgrade and reboots on that host's own timeline" (cairn.dunn.dev, running page, "Day two").

The principle: the operating system is a container image. bootc gives "transactional, in-place operating system updates using OCI/Docker container images" (bootc.dev/bootc, fetched 2026-10-19).
The recipe is a Containerfile anyone can read; the image is addressed by digest in a registry; the host boots it, updates by pulling the next one and rebooting, and keeps the previous one to roll back to (cairn.dunn.dev running and pipeline pages; the health gate, face 15).
Same tool on the Red Hat side: "Image mode for RHEL uses container technology to manage the operating system as an Open Container Initiative (OCI) container image", and "Image mode for RHEL is available by using the registry.redhat.io/rhel10/rhel-bootc bootc image" (docs.redhat.com, RHEL 10, "Using image mode for RHEL", chapter 1, fetched 2026-10-19).
Mine is Fedora: "The base image is composed from Fedora packages into a from-scratch root, then layered" (cairn.dunn.dev, image page). The difference you see from outside is the FROM line.
The read-only /usr and the /etc, /var split are off the face: they are not on the bootc landing page I fetched today, so I do not claim them.

One base, then variants for what the hardware needs: plain, with filesystem modules, with GPU modules, with both, and one for virtual machines (base images/variants.yml, five rows; class labels only on the face).
Each server is a tiny repo that says FROM base:<tag> plus its own config (every instance .gitlab-ci.yml sets base_image to a :stable tag; gitlab.com/dunn.dev/cairn/example).
The tag the instance's base line names is what it follows. Two are in use: :stable, the tested digest, which :latest shares ("for tag in latest stable", pipeline templates/promote.yml); and :stable-sealed, "minted only from a sealed candidate that BOOTED green under enforcing Secure Boot" (base .gitlab-ci.yml). Per-commit tags also exist, pushed at build before any gate.
bootc can follow any tag, said once. My hosts follow :stable or :stable-sealed; there is no other channel in the repos. Which host follows which tag stays off the slide.

A host receives two things from two places. The image is pulled from CI: package set, kernel arguments, users, firewall zones, sshd drop-ins, enabled units, the signed out-of-tree modules and the public half of the Secure Boot certificates (https://cairn.dunn.dev/architecture/image/).
The image is a public artifact, "so it carries only what is safe to publish"; the signing key's private half "lives in a masked CI variable that never reaches an image layer" (image page).
Everything on the right lands after boot, on the host's own timeline, by config management: service config, secrets, SSH keys, registry auth. The image carries none of it, and nothing crosses from that side into the image.
The one hands-on step outside both boxes is re-binding the TPM after a key change: a documented operator procedure, not baked automation (https://gitlab.com/dunn.dev/cairn/base/-/blob/main/docs/tpm-rebind.md).
"No CI reaches a running host: an operator runs bootc upgrade and reboots on that host's own timeline" (https://cairn.dunn.dev/architecture/running/).

Every commit: build, seal, boot twice, upgrade-path, promote, then the host pulls. The second boot "reboots in place, asserts all of it again, and fails on any error the first boot's shutdown logged" (base .gitlab-ci.yml).
upgrade-path boots the published image, switches to the candidate, reboots, requires the assertions, then rolls back (base .gitlab-ci.yml).
Promote round-trips the registry and asserts the OCI media types, because "composefs re-reads the image config blob at bootc install and day-2 bootc upgrade/switch" (pipeline templates/promote.yml). Then :latest and :stable move together.
"A failed gate leaves the last good image in place" (cairn.dunn.dev pipeline page). The pull is the operator's: bootc upgrade and a reboot on the host's own timeline (running page). "A promotion posts a trigger to each instance and never waits on it" (pipeline page).

Real hardware needs out-of-tree modules; here, filesystem and GPU modules. "Kernel modules are compiled from source against the exact kernel the compose installed, never DKMS and never akmods" (cairn.dunn.dev image page, 2026-10-19). The toolchain is "present for one RUN, in no layer" (pipeline page).
They are signed in the build with the key that signs the boot image: "there is no second signing identity" (cairn.dunn.dev image page). "The signing key is readable while the modules are built and absent from everything that ships" (pipeline page).
Debugged in CI, not on a host: cairn-verify "checks the shipped files against a manifest derived at build time from the builders' own install records, so a stray dnf install cannot clobber a source-built module unseen"; manifest-gate diffs module manifests against committed goldens (image and pipeline pages).
The boot test proves they load. Receipts from the catalog README, boot job of 18 Oct: secureboot=yes lockdown=integrity sig_enforce=yes; modinfo -F signer shows the image's own identity; the filesystem module loads (rc=0, in lsmod); the GPU module returns "No such device" and is classed enodev-no-gpu-benign(sig-accepted): the CI guest has no GPU, so the kernel accepted the signature but the driver cannot run. Do not claim the GPU driver is tested on a GPU in CI.
Negative control: with the signing key unset the guard must fail closed; public red job gitlab.com/dunn.dev/cairn/pipeline/-/jobs/16462814933 (2026-09-12) is the commit where it did not.

The boot gate is a VM inside the job's VM: "Nested-VM job: boots a candidate guest inside the job VM" (base .gitlab-ci.yml). The golden VM is itself a read-only bootc image with qemu, swtpm and firmware baked in, so "nothing is installed at job time anymore" (base .gitlab-ci.yml, about line 311).
"boot gates need a protected runner with nested virtualisation" (cairn.dunn.dev, pipeline page). Say "the boot test needs a runner that exposes /dev/kvm"; whether GitLab's hosted runners lack it is unconfirmed, so I do not claim it.
What the gate asserts: secureboot=yes, lockdown=integrity, sig_enforce=yes, the root digest on the signed command line, and all of it again after an in-place reboot (receipt line "GATE-SEALED-BOOT: ...", base sealed-boot job, 2026-10-18).
Where it is written up: the catalog, gitlab.com/dunn.dev/cairn/pipeline, templates/sealed-instance/README.md, which states the protected sealed-boot job needs nested KVM and the golden toolset.
Green and red runs of this gate are public in the base project's CI (a green sealed-boot on 2026-10-18 at 112 seconds; a red on 2026-09-28 where the image booted under enforcing Secure Boot and then an assertion did not hold).

Decide what a gate must prove, then break exactly that on purpose.
12 Sep, build: with the module-signing key unset, the guard exited 0 where it must fail closed, and the control printed "FAIL: vars mode with MOK_SIGNING_KEY_B64 unset exited 0 - fail-closed is GONE" (https://gitlab.com/dunn.dev/cairn/pipeline/-/pipelines/2843113289, job https://gitlab.com/dunn.dev/cairn/pipeline/-/jobs/16462814933). A feature-branch run.
02 Oct, seal: a world-writable file in the sealed tree failed the seal self-test (https://gitlab.com/dunn.dev/cairn/pipeline/-/pipelines/2905336957, job https://gitlab.com/dunn.dev/cairn/pipeline/-/jobs/16886538062). A feature-branch run.
28 Sep, boot, on main: the sealed image booted under enforcing Secure Boot, then an assertion did not hold; a unit in the guest failed (https://gitlab.com/dunn.dev/cairn/base/-/pipelines/2888347958, job https://gitlab.com/dunn.dev/cairn/base/-/jobs/16771092964). Say "a red run", not "red on main" for the first two.
A failed sealed boot freezes both :stable and :stable-sealed on the last good digest, and a red run is deliberately not retried: "a broken candidate can pass on a lucky retry" (base .gitlab-ci.yml, https://gitlab.com/dunn.dev/cairn/base). For contrast, the green gate of 18 Oct ran 112 s: https://gitlab.com/dunn.dev/cairn/base/-/pipelines/2960067517.

Day two on a host: pull, reboot, health gate, roll back if it fails. The pull and reboot are mine, on the host's own timeline (cairn.dunn.dev, running page).
The health gate counts consecutive failed boots in /var; "Below the threshold it reboots to retry; at the threshold it invokes bootc rollback", default threshold 3; with no rollback target it does not reboot, so no boot loop (cairn.dunn.dev, running page). It is a host-level add-on, not part of the base or the example.
Upstream bootc, composefs backend: "There is no bootc-boot-complete.service and no boot counting" (bootc.dev/bootc/bootc-composefs.7.html, fetched 2026-10-19), which is why the health gate is a host add-on.
The size figure, stated exactly: about 5% of the image re-shipped on a same-commit daily rebuild: 43.8 of 832.5 MiB (5.3%), one pair of days, 2026-10-17 to 10-18, flagship base only, host layers not rechunked and not in the figure (chunkah v0.7.1). Before the newer rechunker: 50.2%. Never say "5% per update"; a new commit re-ships the big files.
Pipeline time, if asked: main pipelines that build and boot the image (duration 30 minutes or more), median 56 minutes, n = 129, 3 Aug to 19 Oct 2026; since 29 Sep, median 41, n = 46 (public pipelines list, recomputed 2026-10-19).

Four links in the chain: a key I minted offline signs the boot image; the boot image carries the root filesystem digest on its kernel command line; the kernel checks that digest; every file read is verified against it. Red Hat's words: "bootc container ukify creates the UKI with that digest in the kernel command line (composefs=<digest>)" (https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/using_image_mode_for_rhel_to_build_deploy_and_manage_operating_systems/cryptographic-sealing-of-bootc-images-technology-preview).
The per-file check is fs-verity. A file is cut into blocks, usually 4 KiB; each block is hashed, the hashes are hashed in groups, level by level, until one root remains. The kernel re-verifies a block every time it is paged in, not once, and reads of corrupted data fail (https://docs.kernel.org/filesystems/fsverity.html). On a sealed image the kernel "returns an I/O error (EIO)" and the file is not served (Red Hat sealing doc).
On its own fs-verity is integrity, not authentication: the root has to be pinned somewhere trusted for the check to mean anything against an attacker. Here that is the signed boot image (kernel fs-verity doc; Red Hat sealing doc).
The disk key is released only to a boot this key signed: a LUKS2 slot enrolled against the signed boot state (cairn, https://cairn.dunn.dev/architecture/sealing/). Wrong key, wrong boot: the host falls back to its recovery passphrase, degraded, not bricked.
Scope, if asked: the seal covers the image. Writable configuration in /etc and runtime state in /var are outside it (Red Hat, https://www.redhat.com/en/blog/how-sealed-images-red-hat-enterprise-linux-extend-os-integrity-boot-runtime).

Sealing catches a tampered file when it is read. The next step is the kernel refusing to execute anything whose source it cannot verify, user space included. Upstream that is Integrity Policy Enforcement, a Linux security module: it "targets the risk of tampering with user-space executable code after the kernel has initially booted" and verifies "the integrity and authenticity of all executable code before allowing them to run" (https://docs.kernel.org/admin-guide/LSM/ipe.html).
The topology: an executable comes from somewhere. A dm-verity volume with a signed root hash, or an fs-verity file with a signed digest, are sources the kernel can vouch for; anything else is not. A signed policy, chained to the kernel's trusted keyring, lists rules top to bottom with a default per operation; the kernel evaluates it on every exec and allows or denies (kernel IPE doc: operations, properties, policy format).
What Red Hat has said: sealed images verify every OS file on read, "The system refuses to load any OS file that does not match", a Technology Preview in RHEL 10.2 (https://www.redhat.com/en/blog/how-sealed-images-red-hat-enterprise-linux-extend-os-integrity-boot-runtime). That post and the RHEL sealing doc say nothing about IPE, and I do not know whether the RHEL kernel enables it. What exists in the open is the composefs project's tracker for IPE integration, issue 360, opened in September 2024 by a bootc maintainer at Red Hat and still open (https://github.com/composefs/composefs/issues/360).
What I run today: the sealed root verified on read, and kernel modules signed because module loading is a separate kernel path with its own signature check. IPE is not in what I run (https://cairn.dunn.dev/architecture/sealing/).
If asked why it matters: fs-verity by itself "only provides integrity protection"; it exists so that trusted user space, IMA or IPE can build authentication on it (https://docs.kernel.org/filesystems/fsverity.html). IPE is the piece that turns "tamper is detected on read" into "unverified code refuses to run".

Rung 1, fork and keep one lane: a registry path and a short Containerfile; you get a bootable image tagged :latest and :stable. Rung 2, add the catalog's supply-chain and instance components: build, change-path gate, SBOM, promote. Rung 3, choose a base variant: your hardware facts (cairn.dunn.dev; gitlab.com/dunn.dev/cairn/example, README "Fork and roll").
Rung 4, disk encryption posture: a TPM 2.0 host and an off-device recovery passphrase (base docs/tpm-rebind.md). Rung 5, pull-time signature enforcement: a signing keypair. Rung 6, the sealed lane: an offline-minted key hierarchy, a protected nested-KVM runner, two CI variables; produces :stable-sealed. Rung 7, automatic rollback: a health gate on the host.
Thin points: the example's lanes build on the unsealed base; the evidence lane's provenance and SBOM diff are "not yet built".
Takeaways that need none of my code: move packages, kargs, users, zones and units into a Containerfile; gate the tag on a real boot; keep a passphrase slot beside the TPM slot; keep runtime config out of the image; add a health gate that rolls back; publish key fingerprints out of band; skip the daily rebuild when inputs are unchanged.

The chain on top is the direction: signed at build, verified at boot, checked on every read, and the next step, checked before every run. The first three are what sealing gives; the fourth is IPE, upstream in the kernel (https://docs.kernel.org/admin-guide/LSM/ipe.html).
Red Hat is leading the work. Sealed images: "cryptographically seal your boot container images by using your organization's Secure Boot keys", a Technology Preview in RHEL 10.2, not for production under Red Hat's SLAs (https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/10.2_release_notes/technology-preview-features). The runtime direction is in Mark Russell and Colin Walters' post of 20 May 2026: "The system refuses to load any OS file that does not match" and "This is where OS management is heading" (https://www.redhat.com/en/blog/how-sealed-images-red-hat-enterprise-linux-extend-os-integrity-boot-runtime).
Others are doing similar work. Amutable, in Linux: "Our mission is to deliver verifiable integrity to Linux workloads everywhere", layers named build, boot and runtime integrity; the page describes no product or availability (https://amutable.com/about). Oxide, across a whole rack and not Linux: "the switch, the compute sled, and even the power shelf controller have a root of trust", so they "can measure and attest to all of the software in the system" (https://oxide.computer/faq-friday/why-does-the-oxide-power-shelf-have-a-root-of-trust).
If asked what I have sent upstream, status checked 19 Oct: bootc, four PRs merged (https://github.com/bootc-dev/bootc/pull/2536, https://github.com/bootc-dev/bootc/pull/2544, https://github.com/bootc-dev/bootc/pull/2549, https://github.com/bootc-dev/bootc/pull/2543), one open (https://github.com/bootc-dev/bootc/pull/2567); composefs-rs, three merged (https://github.com/composefs/composefs-rs/pull/381, https://github.com/composefs/composefs-rs/pull/384, https://github.com/composefs/composefs-rs/pull/382); systemd, one merged in v262 (https://github.com/systemd/systemd/pull/43396); image-builder, two merged (https://github.com/osbuild/image-builder/pull/2728, https://github.com/osbuild/image-builder/pull/2727).

The OS is an image built in CI (https://cairn.dunn.dev/architecture/image/); one base yields many instances, each a tiny repo on a tag; modules are compiled and signed in the build, never on the host.
The tag waits on a real boot: a candidate boots in a VM under enforcing Secure Boot before :stable moves, and a red run freezes the tag on the last good digest (https://cairn.dunn.dev/architecture/pipeline/).
The root is sealed: the digest rides in the signed boot image and every file is verified on read (https://cairn.dunn.dev/architecture/sealing/). The firmware trusts only my key (https://cairn.dunn.dev/architecture/trust/).
Day two is pull, health gate, roll back, on the host's own timeline (https://cairn.dunn.dev/architecture/running/). How far to go was face 18: pick the rung you need. The next face is your lab.

Three doors. One machine, no CI: bootc.dev/bootc (and, for a RHEL audience, the image mode for RHEL guide on docs.redhat.com). The catalog: gitlab.com/dunn.dev/cairn/pipeline. The example: gitlab.com/dunn.dev/cairn/example (all HTTP 200, 2026-10-19).
What forking takes, from the README: "Fork this project, keep the one lanes/<lane> directory you want, delete the rest ..., point instance_image at your own registry path, edit the lane's Containerfile, and push to main." Four lanes: plain, attended, edge, evidence.
What a fork gets: build, change-path gate, SBOM, promote to :latest and :stable. It does not get the nested-VM boot test; for that a fork needs its own runner exposing /dev/kvm plus the catalog's seal components. The example's main points its jobs at a self-hosted runner; a fork deletes those lines to take the hosted defaults.
The close: all of it is open source, readable and free to use today, at cairn.dunn.dev and gitlab.com/dunn.dev/cairn. If you want to put it into practice, GitLab and Red Hat are where you would do that: the catalog runs on GitLab CI, and image mode for RHEL is the same tool. The thanks face is next, then questions; the backups after it are for the ones I expect.

Mark Russell and Colin Walters of Red Hat, whose sealed-images post is where this talk's idea of sealing comes from: "Trust at every layer: How sealed images extend OS integrity from boot to runtime", 20 May 2026 (https://www.redhat.com/en/blog/how-sealed-images-red-hat-enterprise-linux-extend-os-integrity-boot-runtime). Neither has reviewed or endorsed what I run; I say thanks, not more.
Who they are, in the open: Colin Walters is an engineer at Red Hat and the creator of ostree and bootc (his DevConf.CZ 2026 and All Systems Go 2024 speaker bios); he is a bootc maintainer, listed as an approver in the project's MAINTAINERS file, and by a wide margin its top contributor (https://github.com/cgwalters, https://github.com/bootc-dev/bootc/blob/main/MAINTAINERS.md). Mark Russell is a Senior Principal Product Manager, Technical, at Red Hat, on the RHEL and OpenShift product management teams (his Red Hat author page, https://www.redhat.com/en/authors/mark-russell), listed in the same file as a community representative; his handle comes from that row (https://github.com/marrusl).
Red Hat invited this talk; I thank them for the room.
Jon Polom, a former DoD colleague I have bounced a lot of these ideas off (https://github.com/jmpolom).

After the close

Backups

Twelve faces for the questions I expect. Reached by key or by hash: X1, X2, X3, X4, X5, X6, X7, X8, X9, X10, X11, X12.

For a room that moves bytes over satellite: an OCI image is layers addressed by digest, and a layer the host already holds is not fetched. bootc's pull path logs "layers already present; layers needed" (https://github.com/bootc-dev/bootc/blob/main/crates/ostree-ext/src/container/store.rs); the Fedora community statement is "only pull the layers that are not already on the disk" (https://discussion.fedoraproject.org/t/a-few-questions-about-bootc-and-composefs/178725).
The catch: a single package change can invalidate a layer far larger than the package. chunkah rechunks a flat rootfs into content-based layers, reproducibly with SOURCE_DATE_EPOCH, so a layer is byte-identical across days when its files are; it works with any registry and needs no special client (https://github.com/coreos/chunkah, v0.7.1 published 5 Oct 2026).
What I measured on my flagship base, same commit rebuilt the next day: before, chunkah 0.7.0, 27 of 64 layers changed, 418.1 of 832.4 MiB (50.2%), every large-file layer moved. After, chunkah 0.7.1, 5 of 64 layers changed, 43.8 of 832.5 MiB (5.3%), 22 of 25 large-file layers byte-identical. One image, one pair of days, 17 to 18 Oct 2026, n = 1; my own measurement note, not a published benchmark (the 43.8 MiB breakdown is on X8).
Scope: the saving is for rebuilds of unchanged source. Any new base commit still re-ships the large-file layers, the host's own layers on top are not rechunked, and the other bases were not rechunked.
Not used here: zstd:chunked, which works at pull time with HTTP range requests and needs client support and more CPU and memory on the client (chunkah README). Whether I enable it is unconfirmed; I do not claim it.

Tang is "a server for binding data to network presence": stateless, no TLS, no authentication, and "Tang never sees a single client key" (https://github.com/latchset/tang). Clevis is the client framework; on RHEL this is network-bound disk encryption, a form of policy-based decryption (https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/security_hardening/configuring-automated-unlocking-of-encrypted-volumes-using-policy-based-decryption_security-hardening).
Bind, once: the client asks the server for its public key, derives a key from it, wraps a LUKS key with that, stores the wrapped key in the LUKS header and discards its own private half. The server stores nothing about the client. clevis luks bind creates a new key with the same entropy as the LUKS master key; the existing passphrase still works (RHEL doc).
Every boot: the initramfs, with clevis and network, sends a blinded request; the server does one math step with its private key and returns a blinded answer; the client unblinds, recovers the key and opens the disk. The blinding makes request and response indistinguishable from random; this is the McCallum-Relyea exchange (Tang README).
The consequence: a stolen disk is useless away from a reachable server, and the server never sees the disk key or the client's key. For availability, the sss pin shares the secret across several servers (RHEL doc).
What the initramfs needs: clevis, clevis-luks, clevis-dracut, rd.neednet=1, a rebuilt initramfs with network, DNS and a CA bundle (RHEL doc; keystone setup, https://gitlab.com/dunn.dev/keystone). I keep a passphrase slot beside it.

keystone is a Tang server that "runs as a Cloudflare Worker, speaks the protocol of stock tangd and serves many named key sets from one deployment"; it is for hosts that cannot reach a tangd on a LAN. Released as v0.2.0 on 12 Oct 2026, shared as-is, and not running on my hosts (https://gitlab.com/dunn.dev/keystone, https://gitlab.com/dunn.dev/keystone/-/releases/v0.2.0, https://keystone.dunn.dev/architecture/).
The origin gate, per key set: an allow list of network prefixes served unattended, and one to five approvers who get a mail to approve or deny any other origin. Recovery "serves origins inside allow, holds others until an approver approves by mail, and refuses the rest". An approval serves that /24 or /48 for 10 minutes; the held host is served within about 15 seconds because clevis-luks-askpass keeps retrying; a one-shot client fails (README).
After an unlock from a new source the set mails an alert, at most one an hour per set, with up to five sources waiting for the digest: a tripwire, not an audit log. Approval mail is capped at 5 an hour per approver and 40 across all sets (README).
Keys are write-once in Worker secrets, so rotation uses a new name: mint server-2, bind a new slot, reboot to prove the unlock, unbind the old slot, revoke the old set. "A revoked set answers 404, and its disks stop unlocking from then on. A host that already unlocked keeps its disk key." Never roll a Worker back across a revoke: versions carry secrets (README, setup.md).
Trust: "whoever controls the Cloudflare account controls the keys"; split it by binding with clevis sss across keystone and a second server. Curves P-521 or P-256, one per set; on the Free plan P-521 needs the paid tier (setup.md, Curves).

NIST SP 800-193 is written for platform firmware, not an OS image; I read its three principles against what I run, by analogy at the image layer, and say "maps to", never compliant or certified (https://csrc.nist.gov/pubs/sp/800/193/final, section 3.1).
Protect: the signed boot image and the read-only root, its digest in the signed command line, enforced by Secure Boot on the boot chain (https://cairn.dunn.dev/architecture/sealing/).
Detect: a changed file fails on read (fs-verity), and the boot gate in CI checks the receipts before the tag moves (https://cairn.dunn.dev/architecture/pipeline/).
Recover, the dashed edges: a failed gate leaves the last good tag in place; the health gate rolls a host back to its last good deployment after three failed boots; a recovery passphrase slot sits beside the TPM slot (https://cairn.dunn.dev/architecture/sealing/).
Own keys: the NSA's UEFI Secure Boot Customization report recommends customizing Secure Boot rather than disabling it, including signing your own boot binaries and drivers; I mint the Platform Key and Key Exchange Key offline, sign image and modules in CI with a key I hold, and the boot gate proves a boot with no Microsoft key or shim in the chain (ver. 1.2, March 2023, https://media.defense.gov/2023/Mar/20/2003182401/-1/-1/0/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20230317.PDF).

Credits

Diagram grammar: diagram-design, MIT, Copyright (c) Cathryn Lavery.
Type: Geist and Geist Mono, Vercel, SIL Open Font License.
The GitLab logo is a trademark of GitLab Inc.; the Red Hat logo is a trademark of Red Hat, Inc. Used to name the user group's hosts and the tools discussed.
Sources: source.android.com, support.apple.com, bootc.dev, docs.redhat.com, csrc.nist.gov, NSA UEFI Secure Boot Customization, cairn.dunn.dev and the public cairn repos at gitlab.com/dunn.dev/cairn.