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.
Sealed Secrets is a Kubernetes controller and companion CLI tool (kubeseal) created by Bitnami that solves a specific GitOps problem: how to store Kubernetes Secret manifests in a Git repository without exposing their contents. A standard Kubernetes Secret is base64-encoded, not encrypted — anyone who can read the manifest file or the Git history can decode the values instantly. Sealed Secrets resolves this by encrypting the secret values using asymmetric cryptography before they ever leave the developer’s machine, producing a SealedSecret custom resource that contains only ciphertext and is safe to commit to any repository, public or private. The corresponding plaintext Secret is materialised exclusively inside the cluster by the controller, which holds the only private key capable of decryption.
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.
MACsec (MAC Security, IEEE 802.1AE) is an IEEE standard, first published in 2006 and supported in the Linux kernel since 4.6 (2016), that encrypts and authenticates Ethernet frames at layer 2 — hop by hop between directly connected devices. Its operating layer is what distinguishes it from IPsec (layer 3) and TLS (layer 4): MACsec wraps Ethernet frames, not IP packets or TCP streams, so it can protect every byte that traverses a link segment regardless of what protocol it carries. ARP replies, DHCP offers, LLDP frames, routing protocol adjacencies, and layer-2 broadcast traffic are all encrypted and authenticated alongside application data — something neither IPsec nor TLS can accomplish because both require an IP header to already be present and unenforced. The topology implication of this is that MACsec is link-local and hop-by-hop: it encrypts between two directly adjacent Ethernet peers (a host and a switch, or two switches), decrypts at each hop for forwarding decisions, and re-encrypts toward the next hop. It cannot stretch across a routed boundary; for that, IPsec is the right tool.
LUKS (Linux Unified Key Setup) is the standard specification for block device encryption on Linux, created by Clemens Fruhwirth in 2004. It sits above the kernel’s dm-crypt subsystem — which performs the actual AES sector-by-sector encryption via the device mapper — and adds a structured, on-disk header that decouples key management from the encryption itself. Any block device can be a LUKS container: a partition, a logical volume, a loop device; anything that sits beneath it (filesystem, swap, LVM) is encrypted transparently, with no changes required to the software using it. The managed cryptsetup tool and the libcryptsetup library provide userspace access to LUKS volumes, and are the canonical interface for all operations on them.
KMS v2 (Kubernetes KMS Provider version 2) is the stable (GA since Kubernetes 1.29, KMS v1 deprecated in 1.28 and disabled by default in 1.29) mechanism for encrypting the contents of the Kubernetes etcd datastore at rest using an external key management service. Without encryption, Kubernetes Secrets stored in etcd are base64-encoded — trivially decodable by anyone with read access to the etcd data files or a snapshot. With KMS v2 enabled, resources written to etcd — Secrets, ConfigMaps, and any other API objects selected by the EncryptionConfiguration — are encrypted before being persisted, using a unique per-object key derived locally. The envelope encryption scheme means those per-object keys are never stored in plaintext: only their encrypted form lives in etcd, and only the external KMS holds the wrapping key. The encryption configuration is declared in a file referenced by the API server’s --encryption-provider-config flag, with kms: apiVersion: v2 selecting the KMS v2 code path, and endpoint: unix:///path/to/plugin.sock pointing at the plugin’s Unix domain socket.
IPsec (Internet Protocol Security) is a suite of IETF standards (core specification RFC 4301) that adds cryptographic security to IP packets at the network layer, transparently to applications running above it. Where TLS secures a specific connection between two application endpoints, IPsec secures all IP traffic between two hosts or networks — including traffic from applications that have no TLS support, protocols that predate encryption (routing protocols, SNMP, ICMP), and layer-3 metadata that TLS cannot protect. IPsec provides two protocol headers: AH (Authentication Header, IP protocol 51) signs the IP packet including immutable header fields, providing integrity and source authentication without confidentiality — rarely used in modern deployments because NAT rewrites fields that AH covers. ESP (Encapsulating Security Payload, IP protocol 50) encrypts the payload and provides authenticated encryption with AES-GCM or ChaCha20-Poly1305, optionally protecting the inner IP header as well; ESP is the universally deployed choice. Both operate in two modes: transport mode protects only the payload of an existing IP packet (used for host-to-host encryption between endpoints that share routing), and tunnel mode encapsulates the entire original IP packet inside a new one with new source and destination addresses — the basis of VPN gateways where traffic from one network is tunnelled to another through the public internet.
AES (Advanced Encryption Standard), standardised as NIST FIPS 197 in 2001, is the symmetric block cipher that underlies virtually all data encryption in modern infrastructure. It was selected through a five-year open competition that evaluated 15 candidate algorithms; the winner, Rijndael (designed by Joan Daemen and Vincent Rijmen), became AES. A block cipher takes a fixed-size block of plaintext and a key and produces a fixed-size block of ciphertext — AES always operates on 128-bit (16-byte) blocks, regardless of key size. Three key lengths are standardised: AES-128 (128-bit key, 10 rounds), AES-192 (192-bit key, 12 rounds), and AES-256 (256-bit key, 14 rounds), providing 128, 192, and 256 bits of security respectively against classical attacks. AES-256 is the conservative choice for data with long confidentiality requirements and is mandated by CNSA 2.0 for national security systems; AES-128 is widely deployed in TLS and provides adequate security for most workloads. The internal structure — SubBytes, ShiftRows, MixColumns, AddRoundKey — is fully public and has withstood over two decades of cryptanalysis; the best known attacks against full-round AES are theoretical and computationally infeasible, requiring work far beyond brute force but not threatening practical security.
