Identity, as deployed
Objective
Section titled “Objective”The IAM and STS sections of this reference describe a service that is not
deployed. There is no iam.shelfcs.com in the
published endpoint list, and no
call in those pages will answer.
This page describes the identity system that does exist. Where it disagrees with an IAM or STS page, this one is what will answer your call.
an internal service, an internal service.
Two identity systems, one account
Section titled “Two identity systems, one account”| Storefront identity | Cloud identity | |
|---|---|---|
| Who runs it | the hosted auth service (Better Auth) | the identity service |
| You are | Your email address | cust-<user id> |
| Credential | Password, then a 15-minute JWT | Cloud password, and EC2 access keys |
| Gets you | Signup, billing, catalog, the Account API | Every cloud API and both consoles |
| Created | When you sign up | At POST /v1/onboard |
They are two accounts created together, and they do not share a session. Neither is IAM.
What the identity service identity is made of
Section titled “What the identity service identity is made of”| Object | What it is | How many you get |
|---|---|---|
| Project | The tenancy boundary. Every instance, volume, image and key belongs to one | Exactly one, named cust-<user id> |
| User | The login. Holds the password and the EC2 credentials | Exactly one |
| Role | What the user may do on the project | Exactly one: member |
| Domain | the identity service’s namespace above projects | Default, always |
| EC2 credential | The access key pair SigV4 signs with | As many as you mint — Access keys |
That is the whole model. One user, one project, one role.
Every IAM concept, and what it maps to
Section titled “Every IAM concept, and what it maps to”| AWS IAM | Here |
|---|---|
| AWS account | the identity service project |
| IAM user | The one the identity service user. You cannot create a second |
| IAM group | Does not exist |
IAM role, AssumeRole | Does not exist. There is no STS, no role assumption, no cross-account trust |
| Managed or inline policy | Does not exist. Authorisation is the member role and the platform’s own policy files, which you cannot edit |
Policy condition keys, aws:SourceIp, MFA conditions | Do not exist |
| Permission boundary, SCP | Do not exist |
| Instance profile | Does not exist. An instance carries no identity of its own and cannot call the API as itself |
| Access key | the identity service EC2 credential — the one concept that survives intact |
| Temporary credentials | Do not exist. Every credential is long-lived until deleted |
iam:PassRole | Not applicable |
| Account root user | The operator, not you |
What this means in practice
Section titled “What this means in practice”Read these as consequences, not as apology:
- You cannot give a teammate narrower access than your own. There is one user. Sharing access means sharing that user’s password or one of its keys.
- You cannot give CI a read-only credential. A key inherits the whole
memberrole — see Access keys. - You cannot separate staging from production inside one account. The project is the only boundary, and you get one. Separation means two accounts, signed up separately.
- An application on an instance cannot authenticate as the instance. There is no metadata-served role. If it needs to call the API, it needs a key on disk, with everything that implies.
- There is no MFA, on either identity system.
- There is no audit log you can read. the identity service and the services log server-side; nothing surfaces it to you.
Policies written for AWS do not restrict anything here. If your security model depends on IAM policy, this platform does not implement it — and it is better you know that from this page than infer it from a policy that silently never applied.
What the member role permits
Section titled “What the member role permits”Everything within your own project: launch, describe and terminate instances; create, attach and delete volumes and snapshots; read images; manage security groups and key pairs; read your own rated usage.
Nothing outside it: no creating projects, users, roles, flavors or images, no reading another project, no operator action of any kind.
The IAM and STS pages
Section titled “The IAM and STS pages”They remain published because they are the specification — the shape the service will take if and when it is built, written against the AWS model and reviewed. Every one of them now carries a notice saying it is not deployed.
Treat them as a design document. Do not write code against them.
Go further
Section titled “Go further”- Access keys — the credential that does exist
- Account developer guide
- Accounts and tenancy
- Quotas and limits
- Service endpoints