Configurar access keys

En OtterStorage cada bucket tiene sus propias claves de acceso: una pareja formada por una access key y una secret key. Estas credenciales identifican y firman tus peticiones a la API compatible con S3, y están totalmente aisladas entre buckets. En esta guía aprenderás a crearlas desde la consola, configurarlas en tus herramientas, rotarlas y revocarlas con seguridad.

El modelo: una pareja de claves por bucket

A diferencia de otros proveedores, OtterStorage no usa una cuenta global con permisos sobre todos los recursos. El modelo es deliberadamente sencillo y seguro:

• Una access key + secret key por bucket. Cada pareja da acceso únicamente a su bucket.
• Aislamiento total. Una clave de un bucket no puede leer ni escribir en otro. No hay escalado de privilegios entre buckets.
• Sin coste por uso. No cobramos por peticiones ni por borrados, así que puedes listar, sincronizar o limpiar con la frecuencia que necesites sin sumar coste por operación.

La consecuencia práctica es que limitar el radio de impacto de una credencial filtrada es trivial: como mucho afecta a un bucket, y revocarla es inmediato.

Crear las claves desde la consola del bucket

Las claves se emiten desde la propia consola del bucket:

• Entra en la consola de OtterStorage y abre el bucket para el que quieres credenciales.
• Ve a la pestaña Access keys del bucket.
• Pulsa Crear clave de acceso. Opcionalmente, ponle una etiqueta descriptiva (por ejemplo, backups-restic o ci-deploy) para identificar para qué la usas.
• OtterStorage genera al instante la pareja access key + secret key.

El resultado tiene este aspecto:

Access key ID:     OTTR4XMPL7KEY9QZ2A0B
Secret access key: aB3xY9kLpQ7mN2vWcR5tZ8dF1gH4jK6sUe0oI2pL
Bucket:            mi-primer-bucket
Endpoint:          https://s3.otterstorage.io
Región:            eu-mad

Guarda la secret key de forma segura

La secret key solo se muestra una vez, en el momento de crearla. OtterStorage no la almacena en claro ni puede volver a enseñártela: si la pierdes, no hay forma de recuperarla y tendrás que crear una clave nueva.

• Cópiala inmediatamente a un gestor de secretos (Vault, 1Password, AWS Secrets Manager, las variables protegidas de tu CI, etc.).
• No la guardes en repositorios de código, capturas de pantalla, tickets ni canales de chat.
• La access key sí es recuperable desde la consola en cualquier momento; lo único irrecuperable es la secret key.

Configurar las claves en tu cliente

Cualquier herramienta compatible con S3 funcionará apuntando al endpoint https://s3.otterstorage.io y a la región eu-mad. Tienes dos formas habituales de proporcionar las credenciales.

Opción A: perfil con aws configure

Crea un perfil con nombre (por ejemplo otter) para no mezclar estas credenciales con las de AWS:

aws configure --profile otter

Responde con los datos de tu bucket:

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

Esto guarda la pareja en ~/.aws/credentials y la región en ~/.aws/config bajo la sección [profile otter]. Para no repetir --endpoint-url en cada comando, añade el endpoint a la configuración del perfil en ~/.aws/config:

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

Comprueba que las claves funcionan listando el contenido del bucket:

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

Para la guía completa de comandos consulta Usar AWS CLI con OtterStorage.

Opción B: variables de entorno

Para procesos efímeros, contenedores o pipelines de CI, suele ser más cómodo pasar las credenciales por variables de entorno. La mayoría de SDK y herramientas (AWS CLI, boto3, rclone, etc.) las leen automáticamente:

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

# Endpoint de OtterStorage (AWS CLI v2 y muchos SDK lo respetan)
export AWS_ENDPOINT_URL="https://s3.otterstorage.io"

Con las variables exportadas, no necesitas perfil ni flag de endpoint:

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

Uso rápido con curl

Si quieres comprobar las claves a bajo nivel, AWS CLI puede firmar una petición HTTP por ti y mostrar el resultado sin ejecutarla, lo que es útil para depurar:

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

Para descargas o subidas puntuales con curl sin firmar a mano, lo recomendable es generar una URL prefirmada con tus claves y usarla directamente:

# Genera una URL temporal firmada con tus claves
url=$(aws --profile otter s3 presign s3://mi-primer-bucket/docs/informe.pdf --expires-in 600)

# Descarga el objeto con curl, sin exponer la secret key
curl -o informe.pdf "$url"

Uso con un SDK (boto3)

Desde código, pasa el endpoint y las claves al crear el cliente. Ejemplo con boto3 (Python):

import boto3

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

# Listar objetos del bucket
resp = s3.list_objects_v2(Bucket="mi-primer-bucket")
for obj in resp.get("Contents", []):
    print(obj["Key"], obj["Size"])

En producción, no escribas las claves en el código: léelas de variables de entorno o de tu gestor de secretos.

Rotación de claves

Rotar las claves periódicamente reduce el riesgo de que una credencial antigua o filtrada siga siendo válida. Como cada bucket admite más de una pareja activa a la vez, puedes rotar sin downtime siguiendo este orden:

• 1. Crea una clave nueva en la pestaña Access keys del bucket (la pareja antigua sigue funcionando).
• 2. Actualiza tus clientes con la nueva pareja: perfil de AWS CLI, variables de entorno, secretos de CI, etc.
• 3. Verifica que todo opera con la clave nueva.
• 4. Revoca la clave antigua una vez confirmado que ya nadie la usa.

Por ejemplo, para actualizar solo la pareja de un perfil existente sin tocar la región ni el endpoint:

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

Comprueba que la clave nueva funciona antes de revocar la anterior:

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

Revocar o eliminar una clave

Cuando una clave deja de usarse o sospechas que se ha filtrado, revócala de inmediato:

• Abre la pestaña Access keys del bucket.
• Localiza la pareja por su access key ID o su etiqueta.
• Pulsa Revocar (o Eliminar). El cambio es inmediato: cualquier petición firmada con esa clave empezará a recibir un error de autenticación.

La revocación es definitiva y no afecta a los datos del bucket ni a las demás claves. Si necesitas seguir operando, crea antes una clave nueva (ver Rotación de claves).

Buenas prácticas

• Una clave por integración. Emite una pareja distinta para cada aplicación, servicio o persona. Así puedes revocar una sin afectar a las demás y sabes exactamente qué usa cada credencial.
• No compartas la secret key. Trátala como una contraseña: nada de repositorios, capturas, tickets ni chats.
• Etiqueta tus claves. Un nombre claro (backups-restic, app-web, ci-deploy) hace la rotación y la auditoría mucho más fáciles.
• Rota con regularidad y siempre tras la salida de un colaborador o ante cualquier sospecha de filtración.
• Usa el aislamiento por bucket a tu favor: separa entornos (producción, staging) en buckets distintos con sus propias claves.
• Prefiere URLs prefirmadas para compartir objetos puntualmente en lugar de repartir credenciales.

Resumen

• El modelo es una pareja access key + secret key por bucket, con aislamiento total entre buckets.
• Crea las claves en la pestaña Access keys del bucket; la secret key solo se muestra una vez, guárdala enseguida.
• Configúralas con aws configure --profile otter o con las variables AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY, apuntando a https://s3.otterstorage.io y región eu-mad.
• Rota sin downtime: crea la nueva, actualiza clientes, verifica y revoca la antigua.
• Una clave por integración, nunca compartas la secret, y recuerda: no cobramos por peticiones ni por borrados.

¿Y ahora qué? Empieza a operar con AWS CLI, automatiza limpiezas con reglas de ciclo de vida o protege objetos críticos con Legal Hold.