Most data on this platform is not encrypted at rest by default. This page states what is encrypted, what is plaintext by default, and exactly who holds which key, including a note about the management cluster, so you can decide what to turn on and what to build yourself.

At-rest status by data class#

Node disks are plaintext. The provisioner writes the OS image and the writable data partition to disk without disk encryption. The OS layers are sealed with dm-verity, a kernel feature that detects any modification of the image, but detection is not confidentiality: anyone with physical access to the disk can read its contents. See Node and OS security for what sealing does and does not protect.

PersistentVolumes are plaintext by default. A PersistentVolume is the disk a Kubernetes workload writes its data to. The storage drivers on this stack create volumes unencrypted. Hetzner Cloud volumes are network-attached and their at-rest handling is Hetzner's, one layer down that you do not configure. Local disks on bare-metal servers are the ones you can encrypt yourself with LUKS, by hand, following the volume-decryptor design. See Encrypt data disks for the design and the manual steps, and LUKS as a building block below for the raw pieces.

etcd is opt-in encryption with your key. etcd is the database where Kubernetes stores every object, including Secrets. Encryption at rest for Secrets is off until you enable it, and the key is one you generate yourself. It protects a copied disk or a leaked backup. It does not protect the live API path: the API server decrypts on read, so any request RBAC authorizes returns plaintext. Least-privilege RBAC is the control for that path, not encryption. Encryption is not retroactive either, so Secrets written before you turned it on stay plaintext until you rewrite them. Rotating the key needs a control-plane roll because the config file is written from the Secret when a control plane provisions. Follow Encrypt etcd to enable it, re-encrypt existing Secrets, and rotate keys.

Key custody#

The etcd encryption key, the kernel module-signing key, and the base verity root hash are the material that matters for data at rest. The table states who generates each, where it lives, and how long it exists.

The etcd encryption key is yours: you generate it, and no external key management service (KMS, a hosted service that stores and serves encryption keys) is involved. It lives in the management cluster because that cluster provisions your control plane and mounts the key into your API server at startup. The management cluster is operated by Syself, so the key is inside Syself-operated infrastructure. This is the tradeoff of a managed control plane: the platform that starts your API server has to hand it the key. What you can verify about that boundary is in What Syself can and cannot do in your cluster .

The dedicated management cluster option closes this caveat. Run the management cluster in your own Hetzner account and the key never leaves your boundary, because no control plane and no key sits in Syself-operated infrastructure. See Run a dedicated management cluster in your own account .

The kernel module-signing key signs every kernel module during the image build so the kernel can refuse unsigned modules at runtime. It is generated inside the build and discarded with it. Nobody, including Syself, holds this key after the build, so it cannot be stolen or reused.

The base verity root hash is not a secret and there is no key behind it. The OS sealing is keyless: the kernel verifies the OS image against this hash, not against a signature, and the hash sits in plaintext on the kernel command line where anyone on the node can read it. Its value is that it is public and re-derivable from the released image, which is how you verify the OS yourself. See Verify node integrity .

LUKS as a building block#

The pieces for full-disk encryption are in the image. The kernel builds in dm-crypt (CONFIG_DM_CRYPT=y), the kernel layer that encrypts block devices, and the image ships the cryptsetup tool that manages LUKS, the standard Linux format for encrypted disks. You can create and open LUKS volumes on a node, for example as the backing device for a storage layer you operate.

No provisioning step creates LUKS volumes, no component manages LUKS passphrases, and no boot path unlocks an encrypted root. Treat dm-crypt and cryptsetup as supported raw material for a design you own, not as a platform feature.

The design to follow is Syself's volume-decryptor: LUKS under the LVM volume group that TopoLVM carves local volumes from, with the LUKS key delivered to the node over the network at boot. It is a design, not a product you can install, so today you build it by hand. Encrypt data disks has the manual steps, the key-delivery model, and the reason there is no turnkey option yet.

No KMS integration#

The platform does not integrate with any key management service. There is no envelope encryption for etcd through a KMS provider, and no component fetches keys from Vault, cloud KMS, or hardware security modules. Every key described here is either yours in a Kubernetes Secret or gone after the build.

One consequence to plan around: if you deploy a volume-encryption layer that stores its keys or passphrases as Kubernetes Secrets, those Secrets inherit etcd's encryption status. With etcd encryption off, your volume keys sit in plaintext in the etcd database. Enable etcd encryption before you store key material in Secrets.

For how the storage backends themselves work, see the storage model . For the sovereignty case built on this custody model, where you own the account, the servers, and the keys, see digital sovereignty with Syself .