Access keys

An access key is a long-lived credential for the S3 API: an access key ID that starts with AKIA, and a secret access key. Open the storage account and its Access Keys tab to see the account's keys with their Status, when they were Created, Last used and their Description. Seeing them needs s3accesskeys/read in the resource group; issuing, disabling and deleting them needs s3accesskeys/write there, which the Owner, Contributor and Storage Operator roles have.

Issue an access key

1. On the Access Keys tab, choose Issue key.
2. Optionally enter a Description (optional) — what the key is for, such as CI deploy.
3. Choose Issue.
4. Access key issued shows the Access Key ID and the Secret Access Key, each with a copy button. Copy both and store the secret somewhere safe — for a workload, in a vault; see Connect from a workload.
5. Tick I have copied the secret access key. and choose Close.

The secret is shown only this once. The platform keeps it encrypted and never shows it again; if it is lost, issue a new key.

Issuing is refused for a new account until the platform has given it its identity, which happens while the account is created. Try again when the account is Running.

With the CLI, which prints the secret once:

stsh s3 key create my-storage -g my-resource-group --set description="CI deploy"

What a key can do

A key signs requests as the storage account's own identity, and every request signed with an active key is allowed on every bucket and object of the account: listing, reading, writing and deleting objects, and creating and deleting buckets while Allow S3 API bucket lifecycle is on. Platform roles do not narrow what a key can do.

Caution

A storage account's server accepts every active access key issued in the same boundary, with the same full access: keys issued for other storage accounts, and keys issued through the API for any other managed identity in the boundary. Treat every access key as a key to all the storage accounts in its boundary, and give it only to clients you trust with all of them. For the same reason, s3accesskeys/write in one resource group is in effect full access to the data of every storage account in the boundary.

Disable or delete a key

• Delete, on the key's row and after you confirm, removes the key for good.
• A disabled key stays listed and can be made active again.

Important

The Access Keys tab shows every key as Disabled, whatever its real status, and offers no Disable button. The API reports a key's status as a number — 0 for active, 1 for disabled — and the tab does not read it. Check and change the status with the API instead.

To disable a key, or make it active again, use the key's id, managedIdentityId and status from stsh s3 key list my-storage -g my-resource-group -o json, and send 1 to disable or 0 to activate:

stsh api PATCH /boundaries/<boundary-id>/resourcegroups/<resource-group>/managedidentities/<managed-identity-id>/s3accesskeys/<id> \
  -d '{"status": 1}'

After a disable or a delete the storage server stops accepting the key within about five seconds.

Deleting a storage account deletes its identity, and its keys are removed within about 15 minutes. Until then they still work against the other storage accounts in the boundary — delete the keys first if that matters.

Rotate a key

There is no rotate action. Issue a new key, move the clients over to it, then disable the old key through the API and, once nothing fails, delete it.

Last used

Last used is not recorded yet and shows Never for every key. To see which credentials are in use, read the account's audit log.

Temporary credentials

Instead of a long-lived key, you can get credentials that expire by themselves. They are issued through the platform's API and need s3sts/issue in the storage account's resource group, which Storage Operator, Contributor and Owner have:

stsh api POST /boundaries/<boundary-id>/resourcegroups/<resource-group>/resources/s3storageaccounts/<account>/sts/sessions \
  -d '{"ttlSeconds": 3600}'

The answer holds an accessKeyId that starts with ASIA, a secretAccessKey, a sessionToken and expiresAt. ttlSeconds is 900 to 43 200 (15 minutes to 12 hours); leave it out for one hour. Temporary credentials work only on the storage account they were issued for, and give the same full access to it as an access key. S3 clients take the session token as the third part of the credentials — see Connect to a storage account.