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

Security

Fourteen places where one party’s system meets another’s, in plain words: what crosses, what protects it today, and what is not built yet. It is a summary, not a test report. What we do and do not hold in the way of audits and certificates is on the trust page.

Where this is true

There is no production service yet. Everything below is true of our QA deployment, which is the one that exists, and of the designs the production service will follow. Where a design is not built, the section says so.

1. The public edge

The website, the console and the API are each served at their own hostname over HTTPS, which redirects plain HTTP to it and sets the browser’s hardening headers, and every deployment tests that. The QA machine’s console and API are also reachable over plain HTTP at the machine’s bare address, with no redirect to HTTPS. Today all of it runs on one machine.

2. Signing in

A person proves who they are to an identity provider, and the control plane turns that proof into a session. Every route of the sign-in surface is rate limited per network address. When a user is disabled, their sessions and API tokens stop working at once. Which acts ask for a fresh sign-in is in the next section.

3. The API

A caller is a signed-in person or a bearer token, and every call is checked against what its role may do before it runs. What each of the five roles may do is one file, the one the running system enforces. Some actions in that file are declared and not yet checked by any code, so a role may be listed for something that nothing enforces.

A few acts ask for a fresh sign-in today, among them creating a data plane, revoking one, and managing the organisation’s identity provider. Confirming a held raise, relaxation or removal of a recorded spend cap asks for one too, and that is checked. Deleting a project asks for one too. A token can never provide one. The file marks other acts as needing one, among them deleting an organisation or an environment, and those are declared and not enforced yet. Several acts that grant access or remove data ask for none at all: managing members, creating organisation-wide tokens, applying a change to production, and removing a table by deleting its file.

A spend cap is a file in your configuration repository, and it is recorded only: the cap limits no query yet. What is checked today is a weakening of it. A push that raises the amount, relaxes hold to alert, changes the currency or the period, or removes the file is not applied by a control plane replica that runs the check: it keeps the value it had and lists the change as held, until an owner or an admin confirms it with a fresh sign-in. The check covers a lowering, and an environment’s first cap, only when it would sit below the metered work already counted this month plus what is in flight (a held first cap leaves the environment with no cap until it is confirmed); any other lowering or first cap, from a push or a token, applies at the next sync to any amount. It cannot tell who pushed a change, and it holds this one kind and no other. It is a check in the control plane’s code, so a replica that does not run it, or a change made to the database by hand, does not hold anything.

A few routes answer before anyone is signed in: the sign-in routes, the health checks, and the signed notification a git host sends when you push. A push notification is checked against a secret you provide, a wrong signature is refused, and the route is rate limited. A CI job can also trade its GitHub Actions or gitlab.com identity token for a token of one service principal that lives fifteen minutes unless asked for longer, and an hour at most. The exchange checks the token’s signature against the provider’s published keys, requires it to name your organisation, and issues a token only when one of the principal’s trust policies matches the token’s claims exactly. Every refusal is the same answer, a GitHub token can be exchanged once, the route is rate limited, and the console shows a refused attempt only when the token came from an owner the principal already trusts.

A signed webhook that starts a run of one pipeline is built and is not switched on yet. Switched off, a POST to its route is answered with the same empty 404 it gives for an endpoint that does not exist. Switched on, it checks a delivery’s signature against a secret you hold before it reads the endpoint’s pipeline, principal or limits, refuses a wrong or stale signature with that same answer, rate limits the route by network address, and limits how many runs one endpoint can start.

5. Our own staff

Our staff sign in separately from customers, to a console of their own, with their own roles and their own permission matrix, and anything touching a plane, money or access needs a fresh sign-in. Staff actions are kept in a ledger that refuses every change. What a staff member does in your organisation through that console, including a read of your activity, is written into your own audit log under the actor kind staff.

That is not the whole of what staff can do. A support session that needs your consent before staff can act in your organisation is not built yet. Until it is, a staff member can mint an owner’s token into your organisation with a command run on the control plane’s host. The entry that mints it names that staff member, and what the token then does reads as the owner’s own credential. A second host command, which retries provisioning, is recorded as a system actor with the reason typed for it and no staff member; the same retry from the staff console is recorded under the actor kind staff, with the staff member and the reason. Reading your dead-lettered jobs, or the repair state of your projects, in the staff console is written to your chain too, under the staff member, with a count and no names. Reads of the fleet, of cost and of the list of organisations are not written to a customer’s chain. And whoever has access to the host or to the database is outside all of these records.

6. The connection from your plane

Your plane’s agent opens the connection, and the control plane never dials in, so nothing has to be allowed inbound to your cluster.

On our QA deployment that connection is not encrypted in transit: it is plain HTTP/2 to an address on the control plane’s machine, authenticated by a credential the plane presents and an identity proof from the plane’s AWS account that the control plane checks. Encrypting it and authenticating both ends are not built yet.

The messages the plane sends up are checked for form, not meaning. Each field is limited to a shape, such as an identifier, a number, a classifier or a short summary, and the control plane refuses a message that does not fit. A shape limits form, so a short summary can still hold a name or a table name. Going the other way, the text of a query goes down to your plane, and the control plane keeps a sealed, encrypted copy of it for a limited time. A statement a person saves is kept, sealed, until they delete it.

7. Commands sent to your plane

The control plane never opens a connection into your cluster. It records a command, and your plane’s agent receives it over its own connection and runs it with the credentials the plane already has: create a table, run a task, execute a query. A command is redelivered until it succeeds or expires.

8. Your plane and your cloud account

A plane’s data, system and audit buckets are encrypted by default under a key created in the plane’s own cloud account, which for a plane of your own is your account. Each organisation’s data bucket refuses every principal that is not tagged for that organisation, apart from the account root and the provisioning role, and credentials issued for one project cannot reach another.

The control plane does reach into that account, through one role. From an identity of its own, and with an external identifier that belongs to the plane, it assumes the plane’s provisioner role, which the plane’s setup creates in the account. It uses that role to create and manage keys, including to enable, disable and rewrite the policy of a project’s key and to schedule and cancel its deletion, to read and write the data bucket, and to sign links to your storage. Encryption keys says what that means for a revocation. Whose account a plane runs in depends on your plan: The data plane and what stays in your account says how.

9. Engines reading your files

An engine reads files that you or a third party wrote and runs SQL a person typed. Each query runs in a sandbox of its own, with no credentials of yours, so there is no shared process and no shared memory between queries.

The RunningLake runtime lists the version and the licence of every engine and component a plane runs.

10. Model providers

No model is called yet, so there is no prompt that leaves for a provider and nothing that comes back to act on your configuration. This boundary is a design, and it is described on the trust page as one.

11. How results reach your browser

A query’s rows do not pass through the control plane. When a plane publishes a result, it writes it to storage on the plane and the record carries a link to it that is scoped to that result and expires; the control plane is handed that link and is told how many rows and bytes, how long the query took and what it cost.

12. How we build and ship

Nothing reaches our main branch unless every required check has passed on it in a merge queue, or was skipped by a decided change detection because the change gave it nothing to look at. History stays linear, force-pushes and deletions are refused, and the rule binds administrators too. A release is deployed only from a commit that carries a passing run of every required check, with the same exception for a decided skip, to a host whose key is pinned. Dependencies and base images are watched for advisories every week, and the images we release carry a software bill of materials.

Required review of changes to our own code is off until there is a second engineer.

13. The machines we run on

The QA control plane runs on one rented machine. The control plane’s database is dumped every hour, every dump is restored into a scratch database and read back, and an alert fires when the last verified restore is too old. The dump lands on the same disk as the database, so it does not survive losing the machine, and copies kept off the machine are not built yet.

14. Services outside our machines

A few things we depend on do not run on our machines: the certificate authority, the domain registrar and DNS, and the code host and its checks. A public status page that lives outside our machines is not built yet.

What an administrator controls

Members. Owners and admins invite members and give each a role for the whole organisation. A disabled member’s sessions and tokens stop at once. A role limited to one project is not built yet, so every member’s role on every project is their organisation role.
Fresh sign-in. Creating a data plane, managing the organisation’s identity provider and deleting a project ask you to confirm it is you, through your identity provider, within the last five minutes. Signing in is not a confirmation, so the first of them after you sign in asks once, and no token can provide one. Section 3 says which other acts are declared to need one, and which ask for none.
Tokens. An API token has a role and may be limited to one project. Its secret is shown once and cannot be recovered; listing shows its name, role, scope, expiry and last use, including tokens that are revoked or expired. An owner or admin can revoke any token, and an engineer only one they created.
The audit log. Owners and admins read and export it, and reading it is itself recorded. Verify your audit log shows how to check a copy on your own machine. Delivering it to a bucket in your own account is not switched on yet.
Keys. Each plane’s buckets are encrypted under a key created in its own account. Registering your own encryption key is built in the console and is not switched on yet.