Configure access keys

In OtterStorage each bucket has its own access keys: a pair made up of an access key and a secret key. These credentials identify and sign your requests to the S3-compatible API, and they are completely isolated between buckets. In this guide you'll learn how to create them from the console, configure them in your tools, and rotate and revoke them securely.

The model: one key pair per bucket

Unlike other providers, OtterStorage does not use a global account with permissions over every resource. The model is deliberately simple and secure:

• One access key + secret key per bucket. Each pair grants access only to its bucket.
• Full isolation. A key for one bucket cannot read or write to another. There is no privilege escalation between buckets.
• No usage charges. We don't charge for requests or deletes, so you can list, sync, or clean up as often as you need with no per-operation cost.

The practical consequence is that limiting the blast radius of a leaked credential is trivial: at most it affects one bucket, and revoking it is immediate.

Create keys from the bucket console

Keys are issued from the bucket's own console:

• Sign in to the OtterStorage console and open the bucket you want credentials for.
• Go to the bucket's Access keys tab.
• Click Create access key. Optionally, give it a descriptive label (for example, backups-restic or ci-deploy) to identify what you use it for.
• OtterStorage instantly generates the access key + secret key pair.

The result looks like this:

Access key ID:     OTTR4XMPL7KEY9QZ2A0B
Secret access key: aB3xY9kLpQ7mN2vWcR5tZ8dF1gH4jK6sUe0oI2pL
Bucket:            mi-primer-bucket
Endpoint:          https://es-mad-1.s3.otterstorage.io
Region:            eu-mad

Store the secret key securely

The secret key is shown only once, at the moment you create it. OtterStorage does not store it in cleartext and cannot show it to you again: if you lose it, there is no way to recover it and you'll have to create a new key.

• Copy it immediately into a secrets manager (Vault, 1Password, AWS Secrets Manager, your CI's protected variables, etc.).
• Don't store it in code repositories, screenshots, tickets, or chat channels.
• The access key is recoverable from the console at any time; the only unrecoverable part is the secret key.

Configure the keys in your client

Any S3-compatible tool will work by pointing to the https://es-mad-1.s3.otterstorage.io endpoint and the eu-mad region. There are two common ways to provide the credentials.

Option A: profile with aws configure

Create a named profile (for example otter) so you don't mix these credentials with your AWS ones:

aws configure --profile otter

Answer with your bucket's details:

AWS Access Key ID [None]: OTTR4XMPL7KEY9QZ2A0B
AWS Secret Access Key [None]: aB3xY9kLpQ7mN2vWcR5tZ8dF1gH4jK6sUe0oI2pL
Default region name [None]: eu-mad
Default output format [None]: json

This saves the pair in ~/.aws/credentials and the region in ~/.aws/config under the [profile otter] section. To avoid repeating --endpoint-url in every command, add the endpoint to the profile configuration in ~/.aws/config:

[profile otter]
region = eu-mad
output = json
endpoint_url = https://es-mad-1.s3.otterstorage.io

Verify that the keys work by listing the bucket's contents:

aws --profile otter s3 ls s3://mi-primer-bucket

For the full command guide, see Using AWS CLI with OtterStorage.

Option B: environment variables

For ephemeral processes, containers, or CI pipelines, it's usually more convenient to pass credentials via environment variables. Most SDKs and tools (AWS CLI, boto3, rclone, etc.) read them automatically:

export AWS_ACCESS_KEY_ID="OTTR4XMPL7KEY9QZ2A0B"
export AWS_SECRET_ACCESS_KEY="aB3xY9kLpQ7mN2vWcR5tZ8dF1gH4jK6sUe0oI2pL"
export AWS_DEFAULT_REGION="eu-mad"

# OtterStorage endpoint (AWS CLI v2 and many SDKs respect it)
export AWS_ENDPOINT_URL="https://es-mad-1.s3.otterstorage.io"

With the variables exported, you don't need a profile or endpoint flag:

aws s3 ls s3://mi-primer-bucket

Quick use with curl

If you want to check the keys at a low level, AWS CLI can sign an HTTP request for you and show the result without running it, which is useful for debugging:

aws --profile otter s3api list-objects-v2 \
  --bucket mi-primer-bucket \
  --debug 2>&1 | grep "Authorization"

For one-off downloads or uploads with curl without signing by hand, the recommended approach is to generate a presigned URL with your keys and use it directly:

# Generate a temporary URL signed with your keys
url=$(aws --profile otter s3 presign s3://mi-primer-bucket/docs/informe.pdf --expires-in 600)

# Download the object with curl, without exposing the secret key
curl -o informe.pdf "$url"

Use with an SDK (boto3)

From code, pass the endpoint and the keys when you create the client. Example with boto3 (Python):

import boto3

s3 = boto3.client(
    "s3",
    endpoint_url="https://es-mad-1.s3.otterstorage.io",
    region_name="eu-mad",
    aws_access_key_id="OTTR4XMPL7KEY9QZ2A0B",
    aws_secret_access_key="aB3xY9kLpQ7mN2vWcR5tZ8dF1gH4jK6sUe0oI2pL",
)

# List the bucket's objects
resp = s3.list_objects_v2(Bucket="mi-primer-bucket")
for obj in resp.get("Contents", []):
    print(obj["Key"], obj["Size"])

In production, don't hardcode the keys: read them from environment variables or from your secrets manager.

Key rotation

Rotating keys periodically reduces the risk of an old or leaked credential remaining valid. Since each bucket supports more than one active pair at a time, you can rotate with no downtime by following this order:

• 1. Create a new key in the bucket's Access keys tab (the old pair keeps working).
• 2. Update your clients with the new pair: AWS CLI profile, environment variables, CI secrets, etc.
• 3. Verify that everything operates with the new key.
• 4. Revoke the old key once you've confirmed no one is using it.

For example, to update just the pair of an existing profile without touching the region or endpoint:

aws configure set aws_access_key_id "OTTR4XMPL8NEWKEY3CD" --profile otter
aws configure set aws_secret_access_key "nW7zX1cV4bN8mQ2lK5jH9gF3dS6aP0oU2iE4rT6y" --profile otter

Check that the new key works before revoking the old one:

aws --profile otter s3 ls s3://mi-primer-bucket

Revoke or delete a key

When a key is no longer in use or you suspect it has been leaked, revoke it immediately:

• Open the bucket's Access keys tab.
• Locate the pair by its access key ID or its label.
• Click Revoke (or Delete). The change is immediate: any request signed with that key will start receiving an authentication error.

Revocation is permanent and does not affect the bucket's data or the other keys. If you need to keep operating, create a new key first (see Key rotation).

Best practices

• One key per integration. Issue a separate pair for each application, service, or person. That way you can revoke one without affecting the others, and you know exactly what each credential is used for.
• Don't share the secret key. Treat it like a password: no repositories, screenshots, tickets, or chats.
• Label your keys. A clear name (backups-restic, app-web, ci-deploy) makes rotation and auditing much easier.
• Rotate regularly and always after a collaborator leaves or at any suspicion of a leak.
• Use per-bucket isolation to your advantage: separate environments (production, staging) into different buckets with their own keys.
• Prefer presigned URLs for one-off object sharing instead of handing out credentials.

Summary

• The model is one access key + secret key pair per bucket, with full isolation between buckets.
• Create keys in the bucket's Access keys tab; the secret key is shown only once, so store it right away.
• Configure them with aws configure --profile otter or with the AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY variables, pointing to https://es-mad-1.s3.otterstorage.io and region eu-mad.
• Rotate with no downtime: create the new key, update clients, verify, and revoke the old one.
• One key per integration, never share the secret, and remember: we don't charge for requests or deletes.

What's next? Start operating with AWS CLI, automate cleanups with lifecycle rules, or protect critical objects with Legal Hold.