Automatic unlocks for LUKS with Panocrypt policy

Panocrypt lets a LUKS-encrypted Linux server reboot without a typed passphrase when unlock policy allows. It does that without escrowing disk keys. The path is built around standard Linux disk-encryption pieces: LUKS for encrypted volumes, dm-crypt for block-device encryption, and Clevis for network-bound unlock.

Panocrypt adds the operational layer around those pieces: enrollment, source policy, manual approval, one-time unlocks, unlock decision history, and managed unlock revocation.

Managed unlock is separate from optional disk encryption setup. If your server already uses LUKS, the existing-LUKS bind path can use only your distribution’s cryptsetup, Clevis, and the standard Clevis tang pin. No Panocrypt host agent is required for that bind or unlock path.

If you want the smallest proof first, start with Test a temporary LUKS volume. It uses only your distribution’s LUKS and Clevis packages, does not touch a boot disk, and lets you prove allow, deny, and optional manual approval behavior.

What automatic unlock means

Panocrypt decides whether it should participate in a future managed unlock. The encrypted device still owns the local LUKS header, local unlock material, and customer-held recovery paths.

Clevis binds one LUKS keyslot to that device’s Panocrypt unlock URL. At boot time, Clevis runs in the initramfs, asks Panocrypt to participate in the recovery exchange, and opens the Panocrypt-bound LUKS keyslot only if policy allows the request.

Panocrypt does not receive the LUKS passphrase, local unlock key, or disk plaintext. The service stores unlock policy, device state, unlock history, and its side of the cryptographic relationship.

For the narrower trust boundary, see No custody of disk keys.

The Linux pieces

On the server, managed unlock uses familiar Linux components.

Piece	Role
dm-crypt	Performs the block-device encryption and decryption.
LUKS	Manages encrypted volumes, keyslots, tokens, and recovery material.
Clevis	Binds a LUKS keyslot to a network-bound unlock policy.
Panocrypt	Provides the policy-controlled, Tang-compatible recovery service and unlock decision evidence.

If a device already uses LUKS, the bind path can use standard distro cryptsetup, Clevis, and the Clevis tang pin. No Panocrypt-specific host agent is required for that existing-LUKS bind path.

If a supported fresh provider image does not yet use LUKS, the Test assisted setup and Assisted fresh-server setup paths can set up LUKS and connect managed boot unlock on supported provider images.

Read LUKS keyslots and Panocrypt binding for the keyslot model, customer-held recovery material, and removal boundary.

Boot-time flow

On a root disk, Clevis runs early inside the initramfs before the normal system starts. That environment needs networking, DNS or a reachable Panocrypt endpoint, CA certificates, and the Clevis hooks needed to unlock the root device.

At unlock time:

1. Clevis reads the local encrypted unlock metadata from the LUKS header.
2. Clevis asks Panocrypt to participate in the recovery exchange.
3. Panocrypt evaluates device state, source policy, approval requirements, and other unlock controls.
4. If policy allows the request, Clevis combines Panocrypt’s response with the device’s local encrypted metadata and opens the LUKS keyslot.
5. If policy denies the request, Panocrypt does not participate. The disk remains locked unless the operator uses customer-held recovery material or another independent local unlock path.

For the trust proof behind this exchange, including where the unlock key lives and why Panocrypt does not escrow it, read No custody of disk keys.

What automatic unlock is not

Automatic unlock is not a proprietary disk format, key escrow service, data recovery service, remote wipe control, or guarantee that every future boot will succeed.

Disabling unlocks stops Panocrypt from participating in future managed unlock for that device. It does not lock a host that is already running, remove keys from memory, modify a LUKS header remotely, or delete independent local keyslots. See Disable unlocks for the operational boundary.

What policy can decide

Panocrypt policy controls whether the service will participate in a future managed unlock. A device can be broad or narrow depending on the risk model.

Common control points include:

• Device lifecycle state.
• Verified source IPv4 or IPv6 address.
• CIDR ranges and shared Network Access lists.
• Initial defaults set by the enrollment key.
• Device tags.
• Manual approval requirements.
• One-time unlock allowance.
• Temporary deny decisions after a denial.
• Managed unlock revocation.

Examples:

Policy shape	Use it when
Allow only the server’s current registered IP.	You want the smallest routine reboot path for a fixed server.
Allow a provider CIDR or shared Network Access list.	A fleet boots from known provider networks.
Allow 0.0.0.0/0 and ::/0, but require manual approval.	A device roams or has unpredictable source IPs, but a human must approve every managed unlock.
Disable managed unlock.	A device has left the fleet or should stop receiving Panocrypt-managed unlock.
Allow once.	A device needs one planned managed unlock without permanently broadening policy.

For a fixed server, you can do the opposite: allow only the boot-time source IP or provider CIDR and let routine reboots unlock automatically when the device is otherwise allowed.

Use Source IP and one-time unlocks after a device is bound, and Disable unlocks when you need the decommissioning boundary.

Manual approval and notifications

Manual approval adds a human decision before a covered device can complete a managed unlock. Approval groups decide which tagged devices require approval and which members or User Groups can approve, deny, or defer requests.

An approval is single-use. It permits the next successful managed unlock for that approved request. It is an operator-approved one-use unlock, similar in outcome to the device-level Allow once control, but routed through approvers. A later reboot or a new unlock request needs a new decision unless policy has changed.

Approval does not create a general 30-minute unlock window. The short collection window exists so a retrying Clevis client can collect the one approved recovery response.

Read:

• Approval groups for coverage and approver dynamics.
• Mobile notifications for registration, test notifications, and removal.

Choose a safe test

Use the docs overview to choose the smallest proof that answers your trust question.

After any binding path succeeds, go to Source IP and one-time unlocks to test allowed sources, denied sources, and Allow once. Use Disable unlocks and Approval groups for those controls.