Securing the Bare Metal: Debian Provisioning for Defense-in-Depth

When deploying infrastructure for the RemoteRails Appliance, maintaining absolute control over your server’s security posture starts at the earliest stages of deployment. For technical IT buyers and infrastructure engineers evaluating our Defense-in-Depth model, trusting a hosting provider’s pre-baked OS image is a non-starter. Cloud provider images are often laden with telemetry daemons and remote management agents that fundamentally compromise a zero-trust paradigm.

To establish a truly pristine, least privilege environment, we leverage a custom provisioning workflow that bootstraps a minimal Debian machine directly from a rescue environment using debootstrap. While we support dedicated hypervisor deployments utilizing SEV/SNP Confidential Computing as an optional feature, most of our customers deploy our dedicated bare-metal stack with the Docker Engine running directly on the Debian host. This architecture leverages hardware-level SME/TSME memory encryption and IOMMU protection against cold boot and DMA attacks, providing an exceptionally hardened environment for containerized workloads.

This article outlines the architecture and deployment considerations of our standalone Debian provisioning tools, designed to build a highly secure, fully encrypted appliance from the ground up.

Clean Slate Provisioning: Escaping Provider Telemetry

Instead of choosing the default Debian image when ordering a dedicated server, our deployment strategy requires booting into a live, RAM-based Rescue Environment (such as the Hetzner or OVH Rescue System). From here, our primary provisioning scripts wipe the drives and use debootstrap to construct a brand-new Debian OS root filesystem.

Why debootstrap?

• Zero Bloat: It installs only the fundamental packages required for a functioning Linux kernel and userspace.
• No Provider Agents: It guarantees the absence of cloud-init, provider telemetry, or proprietary remote support daemons that phone home or allow out-of-band access to the host OS.
• Cryptographic Certainty: Every package is fetched directly from the upstream Debian repositories and cryptographically verified, ensuring a clean supply chain.
• Dashboard Discretion: Because the OS is manually bootstrapped rather than provisioned through the host’s automated API, the server often appears in the hosting provider’s dashboard as having “no operating system” or simply remaining in “rescue mode.” This provides an extra layer of operational discretion, masking the true nature of your hardened infrastructure even from the provider’s own management plane.

Storage Architecture: RAID & Docker-Optimized Filesystems

The foundation of a reliable appliance is its storage layout. Depending on the hardware footprint, our deployment tools handle complex RAID initialization and volume provisioning tailored for heavy bare-metal Docker workloads.

The Root OS Array

In a standard deployment, the OS resides on dual NVMe/SSD drives configured in Software RAID 1. This provides immediate redundancy for the boot and root partitions. For single-drive edge deployments, our single-drive deployment variant gracefully bypasses the RAID 1 configuration, laying down the OS directly on the primary drive.

The Data Array

For the data payload, our storage initialization utility initializes a hardware-backed array across secondary, high-capacity drives (typically HDDs or enterprise SSDs).

• Performance Tiering: For maximum performance, we default to RAID 10 across four drives, avoiding the severe write penalties and dangerous rebuild times associated with parity RAID on modern dense drives.
• High-Assurance RAID 6 Alternative: For deployments utilizing refurbished or budget-tier dedicated servers (such as OVH’s Eco lines) where storage media may have long power-on times, our alternative storage utility formats the array as RAID 6. This prioritizes maximum fault tolerance over raw speed, providing crucial additional assurance against multi-drive failures on aging hardware.
• Bare-Metal Docker Optimization: For our standard pure Docker environment, administrators bypass the LVM thin-pools commonly used in hypervisor setups. Instead, the arrays are formatted as massive standard ext4 volumes and mounted directly to /data. This optimally supports Docker’s overlay2 storage driver and allows heavy container workloads full access to the ultra-fast storage tiers.

Cryptographic Vault: LUKS2 & Seamless Unlocking

Security is paramount. The primary OS and all payload storage are locked behind LUKS2 argon2id encryption.

To manage decryption without requiring KVM/IPMI access, the deployment process injects a Dropbear SSH server directly into the initramfs (Initial RAM Filesystem).

During the bootstrap phase, your public SSH key is embedded into the Dropbear configuration. When the server boots, it pauses at the initramfs stage and listens on port 2222. An administrator simply SSHs into the bootloader and provides the master passphrase to unlock the root partition.

Furthermore, the secondary data array is encrypted with the same master passphrase as the root OS. This configuration allows the Linux kernel to perform seamless “dual-unlocking” during boot, opening both the OS and Data vaults simultaneously without requiring the admin to enter the password twice.

Tamper-Proof Boot Chain: UKI & Secure Boot

To defend against advanced physical threats, the boot chain is cryptographically sealed. Our standalone Debian workflow includes automated tools to implement Secure Boot and Unified Kernel Images (UKI).

EFI Mirroring & Secure Boot

Our Secure Boot configuration tool automates EFI partition formatting and the injection of custom Secure Boot keys using sbctl. By taking ownership of the Platform Key (PK), Key Exchange Key (KEK), and Signature Database (db), the motherboard will strictly refuse to execute any bootloader or kernel not signed by your private infrastructure keys.

UKI Formatting

For the ultimate defense-in-depth posture against physical tampering, we bypass the GRUB bootloader completely. Our Unified Kernel Image utility extracts your live network and LUKS boot variables and wraps your Linux kernel, initramfs, and Dropbear SSH keys into a single, monolithic, signed EFI binary block.

• Automated Lifecycle: An injected system package hook ensures that every time Debian updates its kernel, the system automatically builds a strictly aligned UKI and cryptographically signs it.
• Tamper-Proof Boot: Because the boot parameters are cemented directly into the binary signature, an attacker cannot modify the kernel boot flags (e.g., to disable the IOMMU or alter init=/bin/bash) without invalidating the cryptographic signature and halting the boot process.

The Proxmox Alternative: Dedicated Hypervisor Deployments

While our primary focus is the bare-metal Docker configuration, our provisioning suite also fully supports building a Dedicated Hypervisor appliance utilizing Proxmox VE. When this deployment path is chosen, the architecture shifts to accommodate heavy virtualization workloads:

• LVM Thin-Provisioning: Unlike the Docker deployment (which utilizes massive ext4 volumes for overlay2), the Proxmox path relies heavily on LVM Thin-Provisioning. Our scripts automatically carve out thin-pools (e.g., hdd-thin-pool) on top of the encrypted arrays, allowing Proxmox to efficiently spawn raw, block-level virtual disks for VMs. Crucially, our formatting utilities enforce strict safety margins, ensuring an absolute unallocated buffer (typically 100GB-200GB) is left in the Volume Group. This buffer is critical: if a thin-pool fills up, LVM will attempt to auto-extend. Without unallocated space in the Volume Group, the pool locks up and instantly pauses all running VMs to prevent data corruption.
• Bootloader and LUKS Management: Because Proxmox requires specialized kernel pinning and manages its own EFI mirroring via proxmox-boot-tool, the monolithic UKI (Unified Kernel Image) approach used in our standalone Debian deployment cannot be used. Instead, the hypervisor relies on GRUB and proxmox-boot-tool to manage the boot chain. While the remote Dropbear initramfs unlocking and the seamless dual-array unlocking mechanisms remain functionally identical for the administrator, the underlying boot sequence and LUKS management defer to Proxmox’s native boot tooling rather than our custom systemd-ukify lifecycle hooks.

True Sovereignty Starts at the Bare Metal

By combining debootstrap for a pristine OS, thoughtful RAID architectures for containerized storage, LUKS2/Dropbear for remote cryptographic unlocking, and custom UKI/Secure Boot implementations, this workflow transforms commodity bare-metal hardware into a hardened, sovereign appliance. When combined with SME/TSME memory encryption and IOMMU constraints, it ensures that your data remains confidential and your execution environment remains strictly under your control, entirely independent of the underlying hosting provider’s management plane.