Access keys

Objective

Nothing on ec2.shelfcs.com works without an access key pair. This page is how you get one, rotate one and withdraw one.

an internal service (listAccessKeys, createAccessKey, deleteAccessKey), an internal service.

What an access key actually is

A the identity service EC2 credential. Not an IAM user, not an AWS-style key stored in an identity service of ours — a row the identity service holds against your cloud user, scoped to your project:

the identity service’s credential API

When you sign a request to ec2.shelfcs.com, the EC2 layer hands the signature to the identity service’s the identity service’s signature-verification call to verify. the identity service is the authority on both your password and your access key. Revoking the identity service user revokes both.

[!primary]

The IAM access key actions page describes an AWS-shaped IAM service. That service is not deployed — there is no iam.shelfcs.com in the published endpoint list. What exists today is what this page describes. Where the two disagree, this one is what will answer your call.

Getting one

In the console

Sign in and open Access keys (/keys). It is the same console, opened on that view. Mint, copy, withdraw — no CLI needed.

Through the Account API

Method	Path	Returns
GET	/v1/access-keys	Every key your cloud user holds
POST	/v1/access-keys	201 with a new { access, secret }
DELETE	/v1/access-keys/{access}	204

All three need a session (a Bearer JWT) and an onboarded account. Before onboarding they answer “Become a customer before making access keys.”

curl -X POST https://storefront.job-rss-processor.workers.dev/v1/access-keys \
  -H "Authorization: Bearer $JWT"

{ "access": "…", "secret": "…" }

The one way it does not behave like AWS

[!warning]

GET /v1/access-keys returns the secret, not just the key id. Amazon shows a secret access key exactly once, at creation, and never again — the guarantee being that AWS cannot show you something it does not keep in recoverable form.

the identity service does keep it, and this API returns it. Anyone who can obtain a session token for your storefront account can read every secret you hold, not merely mint a new one. Rotating your keys does not help if the session is the thing that leaked.

Treat your storefront login as equal in power to the keys themselves, and treat a leaked JWT as a full compromise of the account’s cloud credentials.

The practical consequences:

• A key you cannot find again is not lost. Read it back rather than minting a second one and leaving the first live.
• “Show once” hygiene from AWS does not protect you here. Account hygiene does.

Using one

export AWS_ACCESS_KEY_ID=…
export AWS_SECRET_ACCESS_KEY=…

aws --endpoint-url https://ec2.shelfcs.com --region hel1 ec2 describe-instances

provider "aws" {
  region                      = "hel1"
  access_key                  = var.ec2_access_key
  secret_key                  = var.ec2_secret_key
  skip_credentials_validation = true
  skip_requesting_account_id  = true
  skip_metadata_api_check     = true

  endpoints { ec2 = "https://ec2.shelfcs.com" }
}

region must be hel1. It is part of the credential scope every signature carries, and a mismatch returns SignatureDoesNotMatch with nothing in the message that says why.

Rotating

There is no rotation endpoint, and no expiry. A key lives until you delete it.

The safe order:

1. POST /v1/access-keys — mint the new pair.
2. Roll it out everywhere the old one is used.
3. Confirm the old one is idle.
4. DELETE /v1/access-keys/{old access}.

Deleting is immediate and there is no grace period: the next signed request with that key fails. Delete after the rollout, never before.

What a key can do

Everything your cloud user can do, within your project — the member role, no more and no less. See Quotas and limits.

There is no per-key scoping. A key is not narrower than the user that owns it: no read-only key, no key limited to one action, no key limited to one resource, no source-IP condition, no expiry. If you need a credential that can only list instances, this platform cannot yet give you one.

Practically, that means a key handed to CI is a key that can terminate production. Until per-key scoping exists, the separation has to come from using different accounts, not different keys.

How many

No limit is set. Mint one per consumer — one for CI, one for your laptop, one for the tool that only reads — so that withdrawing one does not stop the others. The DescribeKeyPairs SSH key pairs are a different thing entirely and are not affected by any of this.

For internal teams

Internal teams do not go through the storefront. A converging play mints one the identity service EC2 credential pair per tenant and writes both halves straight into Bitwarden, beside the cloud password — never printed to a console and never committed. A team receives an auth URL, a project name and a Bitwarden secret id.

Rerunning the play is a converger: a tenant that already holds a credential gets nothing new, and a tenant missing one gets it back.

Go further

• Account developer guide
• Account API
• Authentication
• Key pair actions — SSH keys, a different thing
• Service endpoints