Credentials and trust
Objective
Section titled “Objective”Read this before deciding how much to trust a session on this platform.
Most clouds are built so that a secret, once issued, cannot be retrieved — only replaced. This one is not, in two places, and both are deliberate design choices with consequences you should know about rather than discover.
Your cloud password is stored, and it is recoverable
Section titled “Your cloud password is stored, and it is recoverable”The cloud password you set at onboarding is kept in the accounts database, in a column that holds it as text — not a hash.
It is kept for a working reason: the console signs in with a username and a password and nothing else, so storing it is what lets the account page open the console for you without asking you to type it again.
POST /v1/console/session→ { "username": "cust-…", "password": "…", "region": "…", "console_url": "…" }That endpoint hands your own password back to your own session.
[!warning]
A password kept in recoverable form cannot be treated like a hashed one.
- Anyone who obtains a session token for your site account can read your cloud password, not merely act on your behalf while the token lasts.
- Do not reuse this password anywhere else. Not your email, not your other clouds, not anything. Treat it as a value the platform holds, because it is.
- There is no password-reset endpoint for it yet, so you cannot rotate it yourself if you think it has leaked. That is the gap that matters most here.
Access key secrets are also recoverable
Section titled “Access key secrets are also recoverable”GET /v1/access-keys returns the secret, not just the key id. Amazon shows
a secret access key exactly once because it does not keep it in a form it could
show again; the identity service here does keep it, and this API returns it.
The consequence is the same shape as above: a session token is not a limited credential. It is a route to every long-lived secret the account holds.
Full detail: Access keys.
So what is the real blast radius
Section titled “So what is the real blast radius”| If this leaks | An attacker gets |
|---|---|
| A site session token (15 min) | Your cloud password, every access key secret, your billing portal link — everything, and permanently, because the secrets outlive the token |
| One access key pair | Full control of your project — no key is narrower than the user |
| Your cloud password | Both consoles and every cloud API |
There is no credential on this platform that is less powerful than any other. No read-only key, no scoped token, no expiry, no MFA, no condition keys. That is documented in Identity, as deployed; this page is about what follows from it.
Practically: the site session is the crown jewel. Protect it accordingly, and do not leave one open on a shared machine.
What is not stored
Section titled “What is not stored”- Your site login password. That belongs to the hosted auth service and this platform never sees it.
- Card details. They belong to the payment provider; the platform holds a customer reference, not a card.
- The contents of your machines or volumes. Nothing reads them.
Where the trust boundaries actually are
Section titled “Where the trust boundaries actually are”| Boundary | What it separates |
|---|---|
| Your account | You from every other customer. The only boundary you get |
| Your project’s network and router | Your machines from other customers’ machines |
| Security groups | Your own tiers from each other — the only tool inside your account |
| The private network | Nothing from you: every machine you run can reach every other |
Two things that must not touch each other need two accounts.
What is not protected yet
Section titled “What is not protected yet”Stated so nobody assumes otherwise:
- No rate limiting. The public edge has none configured, and neither does the authentication endpoint. Do not read the absence as permission — it will arrive.
- No MFA, on either identity system.
- No audit log you can read. Services log server-side; nothing surfaces it to you, so you cannot see when your own credentials were used.
- No IMDSv2. The SSRF defence it exists for is unavailable — see Instance metadata and user data.
- No encryption at rest for volumes.
Encryptedis refused rather than faked, so at least a module asking for it fails loudly. - No provider backups. Nothing here protects you from losing data, only from someone else reading it.
What to do about it
Section titled “What to do about it”- A unique cloud password, stored in a password manager, reused nowhere.
- One access key per consumer — CI, laptop, tooling — so withdrawing one does not stop the others. They are not narrower, but they are individually revocable.
- Separate accounts for environments that must not reach each other.
- Assume a leaked session is a full compromise, and rotate every key if one happens. The cloud password you cannot yet rotate; tell us instead.
- Do not put the only copy of anything here.