Security
Check where your data goes, who holds bucket credentials, how Projects are kept apart, and how long each token lasts.
Table bytes reach the data plane that runs your scans and writes. Embedded execution keeps those bytes in your process and object storage. Hosted execution also sends them through the hosted data plane. This page explains these boundaries, bucket credentials, Project isolation, and token lifetimes.
Where your data goes
| Component | Receives |
|---|---|
| Embedded data plane | Table bytes in your process, directly from object storage |
| Hosted ScanDAL service | Table bytes for scans, writes, blob transfer, and expression evaluation |
| SPFS, Spiral's storage signing service | The method and path of each object request. It signs requests and receives no Table bytes. |
| Control-plane services | Metadata: names, resource and version IDs, commit history, grants, and storage settings |
For signed storage access, the data plane asks SPFS to sign each object request. It sends the signed request directly to the storage provider. A signed request lasts at most five minutes and ends before its storage access expires. With embedded execution, the bytes travel between your process and storage. With hosted execution, the bytes travel through hosted ScanDAL. Architecture describes both execution modes.
Who holds bucket credentials
Spiral stores supplied bucket secrets in a secret store. An identity-based Volume or Connection uses the identity that your bucket trusts instead. Your application does not receive the stored bucket secret.
Your code receives storage access for one resource. With signed access, SPFS signs requests without disclosing its provider credential. With vended access, your code receives a short-lived provider credential for the permitted directory and operations. The provider and the storage configuration determine which method applies.
A data plane with your own cloud identity, without a Spiral-held bucket credential, is planned.
How Projects are kept apart
An Organization holds people and workloads. A Project holds resources, and every resource belongs to exactly one Project. Two boundaries separate Projects:
- Access. Authorization checks the caller's grants for each control-plane request. Revocation prevents new storage access at the next permission check. Existing storage credentials and signed requests can remain valid until they expire. SDK renewal requires another permission check.
- Storage. Each resource has its own directory in its Project's storage. Storage access covers that resource's directory and permitted operations. Storage describes these directories.
Token lifetimes
Every request to the control plane carries a bearer access token. These limits apply to tokens from the Spiral authorization server:
| Token | Maximum lifetime |
|---|---|
| User access token, from sign-in | 1 hour, and no longer than the sign-in session |
| Token narrowed by a token exchange | No longer than the token it narrows |
| Signed storage capability for one resource | 15 minutes, and no longer than the access token it was issued for |
| Vended provider credential | Provider-specific. The returned credential and storage binding state its expiry. |
Older storage token, for workload client secrets (spw_...) and AWS workload federation | 12 hours |
| Signed object request | 5 minutes, and no longer than the storage access behind it |
The twelve-hour storage tokens remain for the two older sign-in methods in the table.
Sign workloads in with a key pair or platform identity instead. See Authentication.
A third-party Application receives a token with scopes when a person delegates access. A scope limits the Application and adds no permission that the person lacks. Delegated tokens never receive the twelve-hour storage tokens.
Related pages
- Storage access explains how access to one resource is issued and renewed.
- Permissions lists every permission and the scope that covers it.