BUILDING Parts of this page describe what is not built yet, and each says so.

Encryption keys

On a plane in your own cloud account each project has a key of its own, in your account. This page says whose key that is, how to supply your own on an AWS plane, what your key’s policy needs, what RunningLake checks when you do, what each state of a key says, what revoking a key does and does not reach, and which parts do not exist.

Registering your own encryption key is built in the console and is not switched on yet.

Whose key it is

On a plane in your own cloud account each project’s key lives in your account, and it is listed in the console under Keys. A project’s key is made for that project alone: the control plane creates it in the plane’s account, through its role, when the project is set up on the plane. The list says where each key came from: Created by RunningLake in your account, or Supplied by you.

A plane we host runs in RunningLake’s cloud account. For its keys the console says: “This plane runs in RunningLake’s cloud account, so this key is RunningLake’s to manage; you cannot revoke it.” On the shared trial plane the Keys screen says: “Your trial runs on the shared trial plane, whose data is encrypted under RunningLake’s own key. You cannot see or revoke it. On a plane in your own cloud account each project’s key lives in your account, and it is listed here.”

A key RunningLake made can be undone by RunningLake’s own role. The role the control plane assumes in the plane’s account can enable a disabled key again, and can cancel a scheduled deletion until its waiting period has passed. The same role can also disable a key, and rewrite a key’s policy. A key you supply changes this only if its policy denies that role the five acts that undo a revocation, and the statements below are how you say so. What a pass of the check shows about that is in what the check shows. Job logs says the same of the project’s key and which key a job log is under.

A plane also has a key of its own. The plane’s key is one key for the whole plane, which also encrypts the plane’s disks, its catalog database and its system bucket, and is the default key of its data bucket where the plane’s setup created it, so disabling it would break the plane. This page is about the project’s key.

Supply your own key

Registering your own encryption key is built in the console and is not switched on yet. It has not yet been tried against a real key. This section and the next three say what it does.

It is offered only for an AWS plane in your own account, and one key serves one project. Supply the key before the project’s first environment is bound to a plane. RunningLake then uses it; it never creates, enables or re-policies it. That is about what RunningLake’s software does. Whether the role the control plane assumes could is what the statements below decide.

1. In the console, open Keys and press Register a key. Choose the project and the plane, and enter the key’s ARN. The full ARN, never an alias: an alias can be re-pointed at a different key without RunningLake seeing it.
2. Press Get the statements. Paste these statements into the Statement list of your key’s policy, between its brackets; the outer brackets shown by your tools are not part of them. Your own statements stay.
3. Press Use this key. Before it records the key, RunningLake checks it: that it is a customer-managed, enabled, symmetric, single-Region key; that the plane’s provisioner role can generate and decrypt a data key with it for this project; that its policy, read as text, refuses the five calls that undo a revocation to each of the six RunningLake roles the statements you pasted name and to every role under the plane’s path; and that the provisioner’s own attempt to cancel its deletion is refused. A pass shows exactly that; what follows from it, and where it stops, is said once the key is recorded. If a check does not pass, nothing is recorded, and the answer says which.

Registering a key needs key.manage, which owners and admins hold, and it asks you to confirm it is you again first. A token can never do it, so a key of your own is registered only in the console, and rl key register and rl key stop make no call and exit 2.

Once recorded, the key cannot be swapped in one step. Until the project’s first environment is bound to a plane you can take it back from the key’s page and record another; after that it stays bound to this project, even if the project is deleted. Taking it back is Stop using this key on the key’s page. Nothing changes in your AWS account. The statements you added stay in the key’s policy until you remove them, and nothing is deleted or scheduled for deletion.

What your key’s policy needs

The console asks the control plane for the statements for the project and the plane you chose, and shows them. They are of two kinds. Some say who may use the key at all and refuse every principal they do not name. The others deny the five acts that undo a revocation (enabling the key, cancelling its deletion, rewriting its policy, adding grants and scheduling its deletion): one statement for each of six RunningLake roles, and one more for every role under the plane’s path.

Use a key made for this one project. The statements refuse every principal they do not name the use of the key, your own administrators and root included, until you rewrite the key’s policy, and two projects on one key would repeat a statement id.

The key’s own root statement is not among them. It is yours, and it must stay in your key’s policy, because the plane’s roles reach the key through their IAM policies because of it.

Nothing checks the key’s policy again afterwards, so keep these statements in it.

What the check shows

The check reads your key’s policy as text, once, when you press Use this key. It makes calls that show in your CloudTrail. One of them is a CancelKeyDeletion on your enabled key, made only after the check has read your key’s policy and found the Deny of it: KMS answers it AccessDenied, which is the refusal the check looks for (a service control policy or a permissions boundary would read the same, and the policy’s text is checked separately). If that call ever succeeded, the check would have cancelled a deletion you had scheduled, and the answer says so.

Once the key is recorded, the console says: “This plane’s RunningLake roles, including any it mints on the plane’s path, cannot undo your revocation.”

That is about this plane, as your key’s policy read once at the time of the check. Until this plane is revoked, and while a project that is not deleted holds a key you supplied on it, RunningLake refuses to register another plane of your organisation in this AWS account and region. The claim above does not cover:

• another plane in your AWS account and region that RunningLake does not count: one registered while the check was running (it can take about a minute), one registered after the project that holds this key was deleted, a plane RunningLake has revoked while its Terraform stack still stands in your account, one registered beside this plane after it was revoked, one that belongs to another organisation, or a stack applied in your account and never registered with RunningLake
• a RunningLake role that is neither named in the policy nor under the plane’s path and is given those permissions later
• anyone in your own AWS account
• any change to the policy after the check

This has not yet been tried against a real key. The Deny for roles under the plane’s path was tried once, on a stand-in role, for two of the five acts.

Once supplying a key is switched on, you can ask again at any time. Check now asks AWS KMS whether the control plane, as the plane’s provisioner in your account, can make a data key under this key and decrypt it. It makes up to three calls that show in your CloudTrail and writes one entry to your audit log. It reads no policy. A check is for a key you supplied. The key’s page says: “A check’s answer is not recorded: the state at the top of this page is what the control plane last recorded.”

What each state says

Each key is in one state, drawn as a word and the sentence below. The state is what RunningLake last recorded about the key, and the console says when AWS KMS last answered. Once supplying a key is switched on, RunningLake asks AWS KMS about each key you supplied on a live plane about every five minutes and records the answer. Each ask is three calls that show in your CloudTrail. A key reads Not checked until RunningLake has tried to ask AWS KMS about it.

The sentences below say what AWS KMS refuses. S3 may go on reading, for a time that has not been measured, with a key derived from yours that it has already cached.

In use

In use. At the time shown, the control plane, as the plane’s provisioner, made a data key under your key and decrypted it. That does not show what the plane’s engines can do: they run as other roles.

Revoked, for a key that is disabled

Revoked: your key is disabled in your AWS account. AWS KMS will not serve data under this key until you enable it, though S3 may go on reading, for a time that has not been measured, with a key derived from yours that it has already cached. RunningLake is running; this is not an outage. Enabling the key in your account restores access, and nothing needs doing in RunningLake.

Revoked, for a key scheduled for deletion

Revoked: your key is scheduled for deletion in your AWS account. Until then, cancelling the deletion and enabling the key restores access. After that date, data under this key can never be read again, by you or by RunningLake.

Revoked, once the deletion date has passed

Revoked: your key was scheduled for deletion in your AWS account, and the deletion date AWS gave has passed, so the key may already be gone. This is the last answer AWS KMS gave; RunningLake has not seen the key deleted. If it is gone, data under it can never be read again, by you or by RunningLake.

Revoked, when AWS KMS refused the control plane

Revoked: AWS KMS refused the control plane’s use of your key after it had worked. A policy or grant in your account may have changed. A service control policy, a permissions boundary, an expired session or a mistake on RunningLake’s side gives the same answer, and RunningLake cannot tell which. This check asks about the control plane’s use only, so it does not show whether your data can be read. An owner or admin can get the statements RunningLake renders for this key on the Policy tab. The key’s own root statement, which lets the plane’s IAM policies reach the key, must stay in its policy too.

Revoked, for a key that has been deleted

Revoked: your key has been deleted from your AWS account. Data under it can never be read again.

Unavailable in your account (nothing produces it yet)

Your key’s external key store is disconnected. Data under it cannot be read until you reconnect it.

Could not check

RunningLake could not ask AWS KMS about this key on its last two tries, three or more minutes apart. This is not a revocation: AWS KMS has not said your key is disabled, scheduled for deletion or withdrawn. Nothing is refused because of it, and RunningLake asks again on its next round.

No verdict

The last check got no answer RunningLake can read as a state of your key: RunningLake may not have been able to ask, AWS KMS may have been busy, or the key may be in a state RunningLake does not word. This shows neither a revocation nor that the key is usable.

Not checked

Not checked yet. No check has been recorded for this key; what is shown is what the control plane recorded when it bound the key. This says nothing about your key.

Not checked, for a key RunningLake made

Not checked. RunningLake made this key and does not ask AWS KMS about it; what is shown is what the control plane recorded when it bound the key. This says nothing about your key.

A revoked state is carried through a silence, so a record can be older than it looks. When the last answer is more than 30 minutes old the console adds: “This is the last answer AWS KMS gave. RunningLake has not had a newer one, so the key may have changed since.”

A key that AWS KMS has deleted is shown as deleted: when AWS KMS answers that the key does not exist, the check reads Revoked, for a key that has been deleted. AWS KMS gave that answer on 26 October 2026, when RunningLake described three of its own test keys after their deletion dates; the check itself has not been run against a real key. AWS KMS may go on answering that a key is pending deletion for some time after its deletion date, and RunningLake has not measured how long: until it answers that the key does not exist, the key reads Revoked, once the deletion date has passed.

When a key is disabled, scheduled for deletion or deleted

Once supplying a key is switched on, a statement sent to the SQL window, from the console, with rl query or through the API, on a project whose key you supplied and the last answer found disabled, scheduled for deletion or deleted is refused, in one sentence, with nothing to retry. For a disabled key: “This project's encryption key (<key id>) is disabled in your AWS account, so its data cannot be read or written and queries are refused. Enable the key in KMS. RunningLake checks the key every five minutes and lifts this when it works again.” For a key scheduled for deletion it says the date, and that cancelling the deletion and enabling the key in KMS is what to do; once the date has passed it says so, and that the key may already be gone. For a key that has been deleted it says the key has been deleted from your AWS account, that its data under it can never be read again and that a deleted key cannot be restored, and it names no remedy and does not say it will lift. A statement is refused only on an answer no more than 30 minutes old, and for those three states and no other: a key that could not be checked, a key AWS KMS refused the control plane’s use of, and a key nothing has asked about do not refuse a statement. The refusal never says who disabled the key.

Only a statement sent through the SQL window, rl query or the API is refused, and only for a key you supplied. Pipeline and task runs, source extracts and streams, file uploads, Python steps and the SQL gateway are not refused on the key’s state, and a statement already sent to an engine is not recalled.

rl query prints the same sentence as it stands and exits 1. The console shows it under the heading Your encryption key is revoked, and adds: “Nothing was run. Running the statement again is refused the same way while the last answer RunningLake has from AWS KMS, under 30 minutes old, says the key is disabled, scheduled for deletion or deleted.”

What revoking does not reach

Revoking a key stops AWS KMS from serving the project’s data under it. S3 can go on reading, for a time that has not been measured, with a key derived from yours that it has already cached; Job logs says the same. It does not reach:

• Query results kept in the plane’s system bucket are under the plane’s key, not yours.
• The catalog’s table names, which live in your plane’s database.
• Control-plane records, such as saved queries, which RunningLake seals itself.
• Your own secrets, which are in your own store.

A lifecycle rule in the plane’s system bucket removes query results 7 days after they are written. S3 runs lifecycle rules once a day, so allow a day more. The rule is in the Terraform module that builds the plane. A plane built before the rule was added gets it with its next apply. The lines of a job’s logs are under two keys in turn: Job logs says which, and what that means for a revocation.

From the command line

rl key list and rl key get read the encryption keys of your projects as the control plane recorded them. rl key check asks whether the control plane can use a key you supplied, and does not record the answer. The command-line reference lists each command, the permission it needs and its exit codes, and Secrets says the same of the secrets commands. Reading a key needs project.read, which every role holds, a viewer included.

Not built yet

These are the things you might expect of encryption keys that do not exist.

• Registering your own encryption key is built in the console and is not switched on yet.
• It has not yet been tried against a real key.
• A run is not held when your key is disabled, scheduled for deletion or deleted: only a statement in the SQL window is refused.
• A key on a cloud other than AWS cannot be supplied: it is refused as AWS-only.
• A key in an external key store or CloudHSM is not supported, and nothing yet produces the state Unavailable in your account.

Back to Security