Encryption in the cloud

Encrypted, each value under its own key, on every plan. Here is what that means in practice.

Two layers

Each version of each value gets a fresh key of its own, and that key is then encrypted by a key belonging to your workspace. This is envelope encryption. The value is sealed with AES-256-GCM under a per-value data key (a DEK), and the data key is wrapped by your workspace's master key held in a key management service.

Two things follow from the shape.

One opened value tells an attacker nothing about the next one, because no two values share a key. And moving to your own master key is a re-wrap of the small keys rather than a rebuild of everything you have stored, because the wrapped data key and the id of the key that wrapped it travel on every version.

The plaintext data key is wiped from memory once the operation finishes.

Each value is sealed to where it lives

The extra data bound into the seal (the AAD) is the value's own address, built from the ids the database holds rather than from the names you type: the workspace id, the project id, the environment id, then the key's path and its name.

2f8c1e0a-...-a41d/9b7e4c22-...-5d10/c0a3f671-...-8e92/redis/password

Ids are what make that binding hold: renaming a project changes nothing the seal was built from, so a rename never costs you a value. A ciphertext lifted from that row and dropped into another environment will not open, because the bytes bound at seal time no longer match the bytes offered at open time. Copying a value between environments, or between workspaces, is not something a database writer can do quietly.

The honest limit

The server can decrypt your values to serve your machines. That is what makes penv pull work.

This is not zero knowledge, and penv does not describe it as such anywhere. A hosted store that hands a value to your CI job has to be able to open that value. What penv offers instead of a claim it cannot keep is a short life for every credential, and a role and a written record behind every read.

If you want to hold the wrapping key yourself, that is BYOK, and it is covered below.

Your own key, on Enterprise

Enterprise workspaces can point penv at a key you own, in AWS KMS, Google Cloud KMS, Azure Key Vault or HashiCorp Vault Transit. Connecting one starts a re-wrap: every stored data key is unwrapped under the platform key and re-wrapped under yours. The sealed value bytes are never touched, and no plaintext value is involved.

Two properties are built into the code rather than into a policy document.

There is no cache of unwrapped data keys anywhere. The row naming your key is remembered for 30 seconds inside each running instance, so standing your key down can take up to 30 seconds to reach every one of them. Your own key service is the authority that refuses in the meantime, so a stale row costs a rejected call and never a wrong answer. And a key id the server cannot place is refused outright. "The customer key failed, fall back to the platform key" is not something the system can express.

Standing a key down is never gated on your plan.

The floor is the same on every plan

Every plan gets envelope encryption and a real key management service. No plan gets weaker encryption than another. What plans do differ on:

• isolation, and where the data sits
• whether you hold the wrapping key
• the compliance paperwork that comes with it

When a value will not open

Every write is a new version and history is kept, so a value you can no longer open is still a row you can recover once the key problem is fixed.

In transit, and on your machine

Traffic between penv and your machines is TLS on every hop. The copy penv keeps on your laptop is a separate thing with its own key in your operating system keychain, described in local mode and cloud mode.

Next: how a machine logs in.