Encrypted virtual machines

#What an encrypted VM is

An encrypted VM is a normal virtual machine built from an encrypted image. Its root disk is encrypted at rest on our storage, and so are its snapshots and backups, because they are copies of that encrypted disk. Each VM has its own key, made on the VM itself the first time it starts.

It is opt-in. The plain images, and every VM built from them, stay exactly as they are. You get an encrypted VM only by choosing one when you create it, and an existing VM cannot be converted: to move to encryption, create an encrypted VM and copy your data across.

Encrypted images today:

Inside the VM it is the same Ubuntu as the plain image: the same users, SSH key login, package updates and kernel updates.

#Where it is available

Encrypted VMs run in zone af-abj-1 as a Standard VPS, and in zone af-abj-2 inside a VPC subnet. The create form only offers encryption where it is available.

#Create an encrypted VM

On the create form, in Image, choose Ubuntu and the version, 24.04 or 26.04. Under the version picker, turn on Encrypt disk at rest. The switch is off by default, and it only appears for a version that has an encrypted image in the zone you chose. If you change the version or the image, check the switch again: it turns off when the new choice has no encrypted image.

Encrypted VMs will carry an extra charge. Its price is not set yet; when it is, the summary shows it as its own line before you create the VM.

From the CLI or the API, you can name the encrypted image's slug wherever you would use the plain one, or ask for the encrypted version of a plain image. With the CLI, --encrypted picks the encrypted version of --image for you, and stops before ordering anything if that image has none available to your organization:

$ pantech vm create --name vault-01 --plan starter --image ubuntu-24-04 --encrypted \    --ssh-key deploy$ pantech vm create --name vault-01 --plan starter --image ubuntu-24-04-encrypted \    --ssh-key deploy

With the API, send encrypted: true in Create an instance with the plain image's slug, and you get that image's encrypted version:

{
  "name": "vault-01",
  "plan_slug": "starter",
  "image_slug": "ubuntu-24-04",
  "encrypted": true,
  "ssh_key_id": "sshk_06gk3x9tq7m2v8r4y1c5d0zp8w"
}

• encrypted: false, or leaving it out, creates the image exactly as named.
• If the image has no encrypted version available to your organization, nothing is ordered and the request is refused with 422 and the code ENCRYPTION_NOT_SUPPORTED on the encrypted field. It is the same answer whether the image has no encrypted version or encrypted VMs are not yet enabled for you.
• encrypted: false together with an encrypted image's own slug is refused as ENCRYPTION_CONFLICT: send true, or name the plain image.

In GET /public/v1/images, an encrypted image has encrypted: true, and encrypted_variant_of names the plain image it is the encrypted version of (ubuntu-24-04 for ubuntu-24-04-encrypted). Plain images have encrypted: false and encrypted_variant_of: null. An encrypted image only appears in the list, and can only be used, once it is enabled for your organization; until then it is refused as an unknown image.

An encrypted VM shows an Encrypted tag on the virtual machine list and on its own page.

#How it starts

The first start takes a little longer. On its first boot, before your system starts, the VM encrypts its root disk in place with a new key made on the VM, then ties the disk to our key servers. The key servers never receive or store your disk's key (see what goes over the network below). The key is held only in the VM's memory while it does this, and is never written anywhere in readable form. After that the VM boots as usual and runs your user data.

Every later start unlocks by itself. While booting, the VM asks our key servers to unlock its disk. There is nothing for you to type, and a reboot, a stop and start, or a power cycle works as on any VM.

#The key servers

There are two key servers, on different hosts, and either one is enough to unlock a VM. They matter only while a VM is starting:

• A running VM does not need them. It keeps running if both are away.
• A starting VM waits for one. If neither answers, the VM keeps trying for 30 minutes and finishes booting by itself as soon as one returns. Until then it cannot start, and its disk stays locked.

Losing one key server does not stop anything. Both being away at once delays starts, not running workloads.

Your firewall rules do not need to allow them. A starting VM reaches the key servers over the network on TCP port 80. Pantech keeps outbound access to them open on the network of every encrypted VM, whatever firewall rules you set. You will not see this rule in your security groups or network ACLs, and you cannot remove it. It allows only the two key servers on that one port.

#What goes over the network, and who can ask

The exchange with a key server is not a delivery of your key. Your disk's key is never sent to a key server and the key servers never store it. At boot the VM and a key server do a short calculation together (a key agreement) over plain HTTP on TCP port 80. The VM sends one blinded value, the key server answers with one computed from its own private key, and the VM combines the answer into the key by itself. Someone watching the network sees values from which the key cannot be worked out. The VM also checks the key server's signed identity against a fingerprint that is built into the image, so a fake server cannot take its place.

What the key servers do not do is check which VM is asking. Anyone who holds a copy of a disk's header and can reach a key server can unlock that copy. That is why the key servers only answer inside Pantech's own network, and why the snapshots and backups of your disks stay on our storage. It protects you against the theft of a disk, a snapshot or retired hardware. It does not stop someone who has both a copy of your data and a position on our network. Encrypted data volumes add the check that is missing here: their key is released only to the instance the volume is attached to.

#Snapshots, restore and resize

VM snapshots, automatic snapshots and backups work as they do for any VM. A snapshot is a copy of the encrypted disk, so it is encrypted too.

• Restoring a snapshot onto the same VM puts the disk back and reboots; the VM unlocks as usual.
• Resizing works as for any VM. When the disk grows, the encrypted root grows with it on the next boot, and the key does not change.
• A new VM built from a snapshot gets its own key. It starts with a copy of the original VM's disk, so at first it shares that VM's key. On its first boot as a new VM it re-encrypts its disk with a fresh key in the background. The VM is usable meanwhile, but expect heavy disk activity for about 10 minutes after that first boot. A reboot, a restore or a resize of the same VM never triggers this.

#Encrypted data volumes

A volume is not encrypted just because the VM it is attached to is. An encrypted VM protects its root disk. To protect a data volume, make it an encrypted volume.

An encrypted volume works on an encrypted VM and on a plain Ubuntu 24.04 or 26.04 VM. It is not tied to one VM: detach it and attach it to any instance of your organization, and that instance can open it. Its key is released only to an instance of your organization that the volume is attached to, after Pantech has checked who is asking.

#Create one

1. Make sure the VM has the agent and is enrolled. An encrypted VM already is. For a plain VM, install the agent and enroll it once (below), before you attach encrypted volumes to it.
2. Create the volume with encrypted: true in Create a volume, and attach it to that VM (send instance_id, or attach it afterwards). It is optional, and a plain volume is the default.
3. The volume reports encryption.status requested. Nothing is encrypted yet. Creating or attaching a volume does not encrypt it.
4. Within seconds of the attach, the agent formats the new, empty disk by itself, with a key from Pantech, and opens it. Only after the platform has confirmed that does the status become encrypted.
5. Create a filesystem on the disk and mount it (below).

The agent formats a disk by itself only when the volume was created with encrypted: true, was not made from a snapshot, and its disk is untouched: no filesystem, no partitions and nothing written. A disk that holds anything is never formatted behind your back. A VM without the agent cannot encrypt the volume, because the format runs inside the VM.

#Encrypted VMs: nothing to install

A VM built from an encrypted image already has the agent, and enrolls itself the first time it boots: when Pantech creates the VM it gives it a one-time token (not a credential), and the agent exchanges that token for the VM's credential, once. The credential is kept in a file only root can read. You do nothing. Create the volume with encrypted: true, attach it, and the agent formats it as soon as it appears, then you create a filesystem and mount it (below).

The token is in the VM's first-boot settings until it is used or 24 hours pass, and it cannot be used twice. If an encrypted VM did not enroll (it was built from an older image, or it was rebuilt, which gives it a new disk), enroll it as a plain VM, below.

#Install the agent and enroll a plain VM

A plain VM, or an encrypted one that did not enroll, needs the agent installed and enrolled by hand. The agent is pantech-vkey. Ubuntu 24.04 and 26.04 only, for now. Ask support for the agent bundle until it has a download link.

$ sudo bash install.sh

Get a credential for this VM with Issue a volume key credential. It is shown once: Pantech keeps only a hash of it, so it cannot be shown again. Then, on the VM, with the address and certificate Pantech gave you:

$ echo "pvk_YOUR_CREDENTIAL" | sudo pantech-vkey enroll --url https://HOST:PORT --ca cert.pem

The credential goes in on standard input, never as an argument, and is kept in a file only root can read. Asking for another credential ends the old one for that VM. A credential also ends when its instance is deleted.

#Mount it

When the agent has formatted the disk it opens it as /dev/mapper/pvk- followed by the disk's serial. sudo pantech-vkey list shows it. Create a filesystem and mount it:

$ sudo pantech-vkey list$ sudo mkfs.ext4 /dev/mapper/pvk-edcaa549e4b340478e0c$ sudo mkdir -p /data$ sudo mount /dev/mapper/pvk-edcaa549e4b340478e0c /data

Use the name list prints instead of the example. To mount it at every boot, add this line to /etc/fstab:

/dev/mapper/pvk-edcaa549e4b340478e0c /data ext4 defaults,nofail,x-systemd.device-timeout=10min 0 2

From then on the volume opens by itself whenever it is attached and whenever the VM boots.

Format it yourself

If you attached the volume before the agent was installed, or want to format a new, empty disk yourself, run the format step directly. The device is the disk's own, for example /dev/vdb (check with lsblk):

$ sudo pantech-vkey format /dev/vdb/dev/mapper/pvk-edcaa549e4b340478e0c

#Move, snapshot and restore

• Move it. Unmount it, detach it, and attach it to another instance of your organization that has the agent and its own credential. It opens on attach. A volume stays on the host it was created on, so it can only move to a VM on that same host.
• Snapshot it. A volume snapshot is a copy of the encrypted disk, so it is encrypted too.
• Restore it. A volume made from a snapshot starts with the same key as the volume it was copied from. Before you can mount it, the agent re-encrypts it with a new key of its own. Nothing can mount it until that has finished, and it takes longer the larger the volume is. If the VM stops part way, the next start resumes it.

#What it needs

• The platform must be reachable when the volume is attached and when the VM boots. If it isn't, the volume stays locked and the agent keeps trying for 30 minutes, then stops until the next boot or attach. A volume that is already open does not need it.
• Your firewall must let the VM reach the platform address and port you enrolled with. Unlike the key servers of an encrypted VM, Pantech does not open this for you.
• The credential is a secret. Anyone who holds it and can attach a volume to that VM can open that volume.
• Growing an encrypted volume is not supported yet: create a larger encrypted volume and copy the data across.

#The older method: volumes opened by the key servers (encrypted VMs only)

Encrypted VMs also carry an older tool, pantech-volume, which encrypts a new, empty volume with a key held by the key servers, like the root disk's. It works only on a VM built from an encrypted image, and the key servers do not check which VM asks. For a new volume, use the encrypted volume above.

$ lsblk$ sudo pantech-volume encrypt /dev/vdb/dev/mapper/pvol-3f6c1a52-8d1e-4f63-9c2a-0b7e5d4a9e11$ sudo mkfs.ext4 /dev/mapper/pvol-3f6c1a52-8d1e-4f63-9c2a-0b7e5d4a9e11$ sudo mkdir -p /data$ sudo mount /dev/mapper/pvol-3f6c1a52-8d1e-4f63-9c2a-0b7e5d4a9e11 /data

Use your volume's own device instead of /dev/vdb, and the name that pantech-volume prints instead of the example. Like pantech-vkey, it refuses a disk that already holds data. From then on the volume unlocks by itself on attach and at boot, sudo pantech-volume list shows your encrypted volumes, and sudo pantech-volume grow pvol-… grows the encrypted layer after you resize the volume.

A volume restored from a snapshot has the same identity as the volume it was copied from, so while the original is attached to a VM the copy can't unlock on that same VM. Detach the original first, or attach the copy to a different VM.

#What Pantech can and cannot access

Your VM's disks, snapshots and backups are encrypted on our storage, each VM with its own key. That protects your data on our disks, on copies of them, and on retired hardware.

Be clear about what it does not do:

• Keys are released by our key servers to a VM that can reach them. They are run by Pantech.

• We hold a recovery key. Each disk and encrypted volume also carries an emergency recovery slot that our recovery key can open, so a disk can be recovered if the key servers are ever lost. That key is kept in a secret manager, apart from the key servers and with restricted access.

• Inside your running VM, your data is not encrypted to anyone who can log in to it. Encryption at rest protects storage, not a running system: keep your access, SSH keys and software secure as usual.

• Deleting is not revoking. Deleting a volume or a VM removes the data as described in deleting a volume. Revoking a credential ends what an instance can ask for, and does not erase any copy of the data. Neither one is a promise that every copy of your data is gone.

• Key rotation. Pantech's master keys are rotated by wrapping keys again under the new key, without touching your data. An old master key is retired only when no volume still depends on it.

So encryption at rest is a strong baseline for data on our storage, not a guarantee that only you can ever open it. If you need keys that only you hold, encrypt the data in your application as well.

#Card data and compliance

If you store card numbers, disk encryption alone does not satisfy PCI DSS 4.0 (requirement 3.5.1.2) for card data. The card number must also be made unreadable by another mechanism, such as encryption or tokenisation in your application. Use encrypted VMs as the baseline, and add application-level encryption for card data. Your own compliance review decides what else your regulator expects.