Sub-Accounts on Z1 Storage: Hard Two-Way Isolation for MSPs

23 July 2026 Cloud Storage

Z1 sub-accounts: one bucket and one key per customer, isolated in both directions

If you manage backups for multiple customers, the uncomfortable question is always the same: what stops one customer's credentials from touching another customer's data? On many platforms the honest answer is "a prefix and good intentions." On Z1 Storage the answer is sub-accounts with hard, two-way bucket isolation — verified by live API testing.

What a sub-account gets

  • Bucket-scoped keys. A sub-account's access keys see and access only the bucket(s) assigned to them. Every request to anything else in the tenant returns Access Denied — the other buckets aren't listed, aren't readable, aren't writable.
  • Two-way isolation. This is the part that surprises people: the parent account's keys cannot access a sub-account's bucket via the S3 API either. Isolation is not merely top-down; each customer's slice is sealed in both directions — strong tenant separation, not a folder convention.
  • Quota caps. Sub-accounts cannot create buckets beyond their assigned allocation, so one customer can never crowd out another.
  • Bucket policies are fully supported when you need finer-grained rules on top.

The MSP pattern

  1. One bucket per customer, created under your tenant. For backup workloads, create it with Object Lock enabled and a default retention rule — every customer's restore points are then immutable on arrival.
  2. One sub-account per customer, scoped to that bucket, with its own access keys.
  3. Configure each customer's backup tool — Veeam, Acronis, a NAS, any S3-compatible client — with their own keys and s3.z1storage.com.
  4. Bill and manage centrally. You keep one relationship with us; your customers each keep a hard-walled slice of storage. A compromised key at one customer reaches exactly one bucket — and if that bucket is lock-enabled, even that key cannot destroy the backups in it.

What this looks like when probed

From a sub-account's credentials:

$ aws s3 ls --endpoint-url https://s3.z1storage.com
# only the assigned bucket appears

$ aws s3 ls s3://another-customers-bucket --endpoint-url https://s3.z1storage.com
An error occurred (AccessDenied)

And from the parent account, against a sub-account's bucket — the same refusal. That is the two-way wall.

One honest caveat

Sub-account keys currently carry full data-plane rights within their own bucket — narrower, action-restricted keys (for example, read-only keys) are under review but not yet available. If a workflow needs a customer to have read-only access to their own backups, handle it at the application layer for now, or pair the bucket with governance-mode Object Lock so even full keys cannot destroy history.

Why it matters

Multi-customer storage usually forces a choice between operational convenience (one big tenant) and safety (separate everything, painfully). Sub-accounts give you both: central management with per-customer blast-radius of exactly one bucket, on POPIA-friendly South African storage at flat R0.30/GB/month.

Building an MSP practice on Z1? Talk to us about sub-account setup and reseller arrangements — or sign up and try the isolation yourself, first 10GB free.

Tags:
Share