Skip to main content

How object storage works

Triton Cloud object storage speaks the S3 API. This page explains where your buckets live, who issues the keys that sign your requests, what tritonctl and the portal can show you, and how an S3 request reaches the service.

One workspace per tenant​

The object store is a service named mantad, run by the operator of your cloud. It keeps its own accounts, called workspaces. Your tenant maps to exactly one workspace, named t- followed by your tenant UUID without hyphens. Every project in the tenant shares it, so object storage is isolated per tenant, not per project.

Inside the workspace are three kinds of objects:

ObjectWhat it is
Storage userAn identity inside your workspace. Storage users are separate from the people who sign in to Triton Cloud.
Access keyAn access key ID and secret access key pair that belongs to one storage user. Your S3 client signs requests with it.
BucketA container for objects. The storage user that creates a bucket owns it.

A tenant has no workspace until the operator binds one. A tenant the operator creates is bound at creation when the cloud has a default storage cluster. A tenant created through self-signup is never bound at creation, even with a default cluster, and neither is one created before the default was set. Until the operator binds it, every tritonctl storage command fails with a 412 and the code TenantStorageUnbound.

The operator issues your keys​

Creating a storage user, creating or deleting an access key, and creating or deleting a bucket through the Triton Cloud API all need the storage-admin capability. That capability belongs to an operator, and the authorization policy refuses it to any principal that belongs to a tenant. To get an access key, ask the operator of your cloud.

The operator receives the secret access key once, in the response that creates the key. Neither tritond nor its audit log keeps a copy, and no list returns it, so a lost secret cannot be recovered. The fix is a new key. There is no rotate operation: rotation is creating a new key, moving your clients to it, and having the operator delete the old one. Keys carry no expiry.

The operator can issue two kinds of key:

  • A plain key acts with the full rights of its storage user in your workspace, minus anything an inline policy on that user denies.
  • A scoped key is limited to a list of buckets. Each entry grants read, readwrite, or full on one bucket, optionally under one key prefix. A scoped key can create a bucket only if it holds full on that bucket's name.

Keys that mantad issues have an access key ID that starts with MKIA, followed by 16 characters, and a 40-character secret.

What you can see without a key​

tritonctl storage and the portal's storage pages read your workspace through the Triton Cloud API. Both are read-only. They list buckets with their object counts and sizes, storage users, and each user's access keys with their status. They never show a secret access key. To create a bucket, or to put or get an object, you use an S3 client with an access key.

Your client talks to mantad directly​

S3 requests do not pass through the Triton Cloud API. Your client sends them to the S3 endpoint of the object store, on port 7443, and mantad checks the signature itself. The Triton Cloud API, tritonctl, and the portal do not display the endpoint, so your operator gives it to you along with your key.

When the operator's cloud has a DNS zone with ACME certificates, the endpoint the control plane records has the form https://s3.<DOMAIN>:7443. Without one, it is plain HTTP on a private address.

Three properties of the endpoint affect client configuration:

  • Path-style addressing only. The bucket name goes in the URL path, https://s3.<DOMAIN>:7443/<BUCKET>/<KEY>, not in the host name. mantad does not parse a bucket out of the Host header.
  • Signature Version 4. Requests are signed with AWS Signature Version 4. mantad refuses a Signature Version 2 Authorization header.
  • The region is a label. mantad accepts a signature made with any region name in the credential scope. The region it reports for a bucket, and the only location constraint CreateBucket accepts, is its configured region, which is us-east-1 unless the operator set another.

Bucket names and quota​

A bucket name is 3 to 63 characters of lowercase letters, digits, -, and .. It starts and ends with a letter or digit, contains none of .., -., or .-, and is not formatted as an IPv4 address. Creating a bucket whose name another owner holds returns 409 BucketAlreadyExists.

Every new bucket starts with a lifecycle rule that aborts multipart uploads left incomplete for 7 days, and with all four public access block settings on.

Your workspace has a byte quota that the operator sets. A write that would exceed it fails with HTTP 507 and the code InsufficientStorage. Each mantad process also rate limits requests per workspace, at 1000 requests per second with a burst of 200 by default. A request over the limit gets 503 SlowDown.

Current limits​

These are properties of the shipped code.

  • A tenant cannot create storage users, access keys, or buckets through tritonctl, the portal, or the Triton Cloud API. Buckets can be created with an S3 client and an access key.
  • The S3 endpoint is not published to tenants by any API, CLI, or portal page.
  • Virtual-hosted-style addressing is not supported.
  • Several S3 features return 501 NotImplemented, among them bucket encryption, website hosting, logging, notifications, and replication. The S3 API reference lists what is implemented.

See also​