Using Clevis + Tang for network-bound automatic disk unlock on a BinaryLane VPS

If you want unattended disk unlock on a VPS but do not have access to a usable TPM, Clevis + Tang can be a practical alternative in the right environment.

This is not the same thing as TPM 2.0. It does not provide a hardware root of trust, measured boot, or TPM attestation. What it can provide is network-bound automatic unlock for a LUKS-encrypted disk when the server can reach a trusted Tang server.

On BinaryLane, the best fit is usually:

  • a VPS inside a private VPC
  • a Tang server reachable only over the private network
  • no public IP on the protected workload where practical
  • tight firewall rules that only allow the required client systems to reach Tang

Why would you use this?

This pattern can be useful when you want:

  • automatic unlock after a reboot
  • encrypted storage without needing interactive console access on each boot
  • a private-network trust boundary instead of storing the unlock secret directly on the workload

Common examples include unattended restarts, encrypted application volumes, and private VPC designs where the unlock service is treated as part of the trusted control plane.

Important caveats

  • This is not TPM. There is no hardware-backed seal or local attestation.
  • The network path matters. If the Tang server is unavailable, unreachable, or filtered, automatic unlock will fail.
  • Have a fallback. Keep an emergency recovery path available, such as console access and the original LUKS passphrase.
  • Use private networking. This approach is much more sensible on a private VPC than over a public network.

What we validated in a BinaryLane lab

We tested this pattern on two BinaryLane Ubuntu 24.04 VPSes in the same Brisbane VPC:

  • one server running Tang
  • one client server with Clevis and LUKS tooling

We validated:

  • private-network reachability to Tang over the VPC
  • successful clevis luks bind against a LUKS2 encrypted test volume
  • successful non-interactive unlock of that encrypted test volume via Tang

We did not perform a destructive root-filesystem conversion in the test environment. If you want to apply this to your root volume, treat that as a separate change with console access and rollback planning.

Example architecture

  • Tang server: small BinaryLane VPS in the same VPC/subnet
  • Client server: protected VPS using LUKS
  • Access control: firewall the Tang service so only the intended private client IPs can reach it

Step 1: Deploy a Tang server on the private network

On an Ubuntu server that is reachable by the protected VPS over the VPC:

apt update
apt install -y tang ufw
systemctl enable --now tangd.socket

Restrict access so only the relevant private client IPs can reach port 80. Example:

ufw default deny incoming
ufw default allow outgoing
ufw allow from 10.10.0.5 to any port 80 proto tcp
ufw enable

Confirm Tang is listening:

systemctl status tangd.socket
ss -ltnp | grep ':80 '

Step 2: Install Clevis on the client

On the VPS that will unlock encrypted storage via Tang:

apt update
apt install -y clevis clevis-luks clevis-initramfs clevis-systemd cryptsetup curl jq

Confirm the client can reach the Tang advertisement endpoint over the private network:

curl http://<TANG_PRIVATE_IP>/adv

Step 3: Bind a LUKS device to Tang

The example below uses a LUKS device and binds an additional unlock method via Tang while keeping the existing passphrase available for recovery.

clevis luks bind -d /dev/<your_luks_device> tang '{"url":"http://<TANG_PRIVATE_IP>"}'

If you want to provide the existing passphrase non-interactively:

echo -n '<existing-passphrase>' | clevis luks bind -y -k - -d /dev/<your_luks_device> tang '{"url":"http://<TANG_PRIVATE_IP>"}'

Check the result:

cryptsetup luksDump /dev/<your_luks_device>

You should see an additional keyslot/token associated with Clevis.

Step 4: Test automatic unlock before relying on it

Do not assume the bind worked without testing it.

For a non-root test volume, a simple validation flow is:

cryptsetup close <mapper_name>
clevis luks unlock -d /dev/<your_luks_device> -n <mapper_name>
mount /dev/mapper/<mapper_name> /mnt

Only after a successful unlock test should you consider using the pattern for something more sensitive.

Applying this to a root disk

Using Clevis + Tang for the root disk is possible, but it carries more risk than a secondary data volume. Before attempting it, make sure you have:

  • console access to the VPS
  • the original LUKS passphrase stored securely
  • a rollback plan if the server cannot unlock at boot
  • initramfs updated after Clevis configuration

On Debian/Ubuntu systems, that usually means ensuring Clevis is installed in the initramfs and then rebuilding it:

update-initramfs -u

The exact root-disk implementation details can vary depending on your current layout, initramfs state, crypttab configuration, and whether you are converting an existing system or building a fresh one.

When this approach makes sense

  • you need unattended unlock and a TPM is not available
  • your servers live on a private VPC
  • you are comfortable treating the private network path as part of the trust model
  • you have a fallback recovery method

When this approach may not be appropriate

  • you need a hardware-backed root of trust
  • the workload or Tang server would need to rely on public network exposure
  • you do not have reliable console/recovery access
  • you cannot tolerate unlock failure when the network path is unavailable

Support scope

As a customer-managed service, our primary support scope is to provide assistance in gaining access to the BinaryLane systems/services and offering general guidance where feasible. We do not provide hands-on (managed) support for issues within your OS: What support options are available?

With that said, if you need help with BinaryLane-side networking, VPC layout, or general suitability of this pattern for your deployment, feel free to contact support.

Last updated: April 2026