Acceso Restringido a Buckets en Storin (Solo Escritura y Solo Lectura)

aviso

⚠️ Todas las configuraciones de este manual son ejemplos. Adapte los nombres de buckets, perfiles y User IDs según su entorno.

📌 Visión General

Esta guía muestra cómo compartir un bucket de Storin con accesos restringidos, por ejemplo:

una credencial que solo sube archivos (write-only), útil para aplicaciones que suben backups o logs;
una credencial que solo lee y lista archivos (read-only), útil para auditoría, consulta o procesamiento.

El control se realiza mediante Bucket Policy.

Otras herramientas

Los ejemplos de esta guía usan la AWS CLI, pero el mismo procedimiento puede realizarse vía API S3, MinIO Client (mc) o cualquier otra herramienta compatible con S3. La Bucket Policy (JSON) es la misma; solo cambia el comando utilizado para aplicarla.

🧠 Cómo Storin aplica los permisos

En Storin, los permisos no se aplican a la Access Key o Secret Key individualmente. Se aplican al User ID (identidad S3) al que pertenece la credencial.

En la práctica:

Cada proyecto del panel tiene una identidad S3, con un User ID propio.
Todas las Access Keys generadas dentro del mismo proyecto usan el mismo User ID y, por lo tanto, tienen exactamente los mismos permisos.
Las claves sirven solo para autenticar la identidad. Lo que se puede o no hacer lo define el User ID referenciado en la policy.

info

Para tener perfiles de acceso diferentes (propietario, solo escritura, solo lectura), cada perfil necesita un User ID diferente, es decir, un proyecto diferente.

Generar una nueva Access Key/Secret Key en el mismo proyecto no crea una nueva identidad.

Ejemplo de estructura

Proyecto	User ID	Uso
Proyecto principal	`USER_OWNER`	Propietario del bucket
Proyecto Writer	`USER_WRITER`	Solo escritura
Proyecto Reader	`USER_READER`	Solo lectura

La Bucket Policy se configura en el bucket del Proyecto principal, referenciando USER_WRITER y USER_READER.

🧰 Requisitos previos

Un bucket ya creado en el proyecto principal (el propietario del bucket).
Una herramienta compatible con S3. En esta guía usamos la AWS CLI; si aún no la ha configurado, siga la guía Configurando la AWS CLI con Storin.
jq instalado (opcional, utilizado para validar el JSON de la policy antes de aplicarla).

🆔 Parte 1 – Creando las identidades (User IDs)

Repita los pasos a continuación una vez para cada perfil restringido (un proyecto para el Writer y otro para el Reader).

Paso 1 – Crear un nuevo proyecto

En el panel, cree un nuevo proyecto. Puede estar en la misma cuenta o en una cuenta diferente a la que contiene el bucket.

Creando un nuevo proyecto

Paso 2 – Inicializar la identidad S3

La identidad S3 del proyecto se genera en el primer uso del Object Storage. Para inicializarla, cree un bucket temporal en este proyecto y, a continuación, elimínelo.

Creando un bucket temporal

tip

El bucket temporal sirve solo para generar la identidad. Puede eliminarse inmediatamente después, sin impacto en el User ID.

Paso 3 – Copiar el User ID

Acceda a la pestaña Accesos del proyecto y copie el User ID que se muestra.

Pestaña Accesos con el User ID

Paso 4 – Generar la Access Key y la Secret Key

Aún en la pestaña Accesos, genere la Access Key y la Secret Key de este proyecto y guárdelas en un lugar seguro. Serán utilizadas por la aplicación o persona que tendrá el acceso restringido.

Generando Access Key y Secret Key

peligro

La Secret Key se muestra solo en el momento de su creación. Guárdela inmediatamente en un lugar seguro, como un gestor de contraseñas.

Al final de esta parte, usted tendrá:

Perfil	User ID	Credenciales
Writer	`<WRITER_ID>`	Access Key + Secret Key
Reader	`<READER_ID>`	Access Key + Secret Key

⚙️ Parte 2 – Configurando la AWS CLI

Configure un perfil para cada identidad (propietario, writer y reader).

Archivo `~/.aws/config`

[profile storin-owner]
region = sp1
output = json
request_checksum_calculation = when_required
response_checksum_validation = when_required
endpoint_url = https://sp1-s3.saveincloud.io

[profile storin-writer]
region = sp1
output = json
request_checksum_calculation = when_required
response_checksum_validation = when_required
endpoint_url = https://sp1-s3.saveincloud.io

[profile storin-reader]
region = sp1
output = json
request_checksum_calculation = when_required
response_checksum_validation = when_required
endpoint_url = https://sp1-s3.saveincloud.io

Archivo `~/.aws/credentials`

[storin-owner]
aws_access_key_id = <ACCESS_KEY_OWNER>
aws_secret_access_key = <SECRET_KEY_OWNER>

[storin-writer]
aws_access_key_id = <ACCESS_KEY_WRITER>
aws_secret_access_key = <SECRET_KEY_WRITER>

[storin-reader]
aws_access_key_id = <ACCESS_KEY_READER>
aws_secret_access_key = <SECRET_KEY_READER>

aviso

Las líneas request_checksum_calculation y response_checksum_validation son obligatorias en la AWS CLI 2.25 o superior. Sin ellas, toda subida falla con ValidationError.

info

Ajuste el endpoint_url según la región de su bucket (por ejemplo, https://sp1-s3.saveincloud.io o https://bsb1-s3.saveincloud.io).

📝 Parte 3 – Creando y aplicando la Bucket Policy

Paso 1 – Crear el archivo de la policy

Cree un archivo llamado policy.json con el siguiente contenido:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowWrite",
      "Effect": "Allow",
      "Principal": { "CanonicalUser": "<WRITER_ID>" },
      "Action": [
        "s3:PutObject",
        "s3:AbortMultipartUpload",
        "s3:ListMultipartUploadParts"
      ],
      "Resource": "arn:aws:s3:::<BUCKET>/*"
    },
    {
      "Sid": "DenyReadForWriter",
      "Effect": "Deny",
      "Principal": { "CanonicalUser": "<WRITER_ID>" },
      "Action": [
        "s3:GetObject",
        "s3:GetObjectVersion",
        "s3:DeleteObject",
        "s3:DeleteObjectVersion"
      ],
      "Resource": "arn:aws:s3:::<BUCKET>/*"
    },
    {
      "Sid": "AllowReadObjects",
      "Effect": "Allow",
      "Principal": { "CanonicalUser": "<READER_ID>" },
      "Action": ["s3:GetObject", "s3:GetObjectVersion"],
      "Resource": "arn:aws:s3:::<BUCKET>/*"
    },
    {
      "Sid": "AllowListForReader",
      "Effect": "Allow",
      "Principal": { "CanonicalUser": "<READER_ID>" },
      "Action": ["s3:ListBucket"],
      "Resource": ["arn:aws:s3:::<BUCKET>", "arn:aws:s3:::<BUCKET>/*"]
    }
  ]
}

Reemplace:

Variable	Valor
`<WRITER_ID>`	User ID del proyecto Writer
`<READER_ID>`	User ID del proyecto Reader
`<BUCKET>`	Nombre del bucket que será compartido

Qué hace cada bloque

Sid	Perfil	Efecto
`AllowWrite`	Writer	Permite subir objetos, incluidas las subidas multipart
`DenyReadForWriter`	Writer	Bloquea la lectura y la eliminación, incluso de los objetos que él mismo subió
`AllowReadObjects`	Reader	Permite descargar objetos y sus versiones
`AllowListForReader`	Reader	Permite listar el contenido del bucket

Paso 2 – Aplicar la policy

La policy debe aplicarse con la credencial del propietario del bucket. Ejemplo con AWS CLI:

jq . policy.json && aws --profile storin-owner s3api put-bucket-policy \
  --bucket <BUCKET> \
  --policy file://policy.json

jq valida el JSON antes del envío. Si hay un error de sintaxis, el comando se detiene antes de aplicar la policy.

Para verificar la policy aplicada:

aws --profile storin-owner s3api get-bucket-policy --bucket <BUCKET>

❗ Reglas obligatorias

Estas reglas son válidas para cualquier herramienta utilizada para aplicar la policy.

El Principal debe usar CanonicalUser

El Principal debe usar CanonicalUser con el User ID en hexadecimal. Las formas a continuación no funcionan en Storin y pueden devolver 403:

"Principal": { "AWS": "<id>" }
"Principal": { "AWS": "arn:aws:iam:::user/<id>" }

El bloque DenyReadForWriter es obligatorio

Quien hace el PUT de un objeto se convierte en propietario de ese objeto y puede leerlo mediante ACL. Sin el Deny explícito, el Writer puede leer todo lo que él mismo subió.

El propietario del bucket no puede ser restringido

El propietario del bucket siempre tiene acceso total, ya que la ownership tiene prioridad sobre la policy. Por eso, la credencial restringida debe pertenecer a una identidad diferente a la del propietario, es decir, a otro proyecto.

✅ Parte 4 – Validando los permisos

Las pruebas a continuación usan la AWS CLI. Con otra herramienta, ejecute las operaciones equivalentes (subida, descarga, listado y eliminación) con cada credencial y compare con la tabla de resultados esperados.

Cree un archivo de prueba:

echo "prueba" > /tmp/t.txt

Writer (solo escritura)

# Debe FUNCIONAR
aws --profile storin-writer s3api put-object --bucket <BUCKET> --key wr.txt --body /tmp/t.txt

# Deben devolver 403 (AccessDenied)
aws --profile storin-writer s3api get-object --bucket <BUCKET> --key wr.txt /tmp/x.txt
aws --profile storin-writer s3api list-objects-v2 --bucket <BUCKET>
aws --profile storin-writer s3api delete-object --bucket <BUCKET> --key wr.txt

tip

Pruebe el GET del Writer sobre un objeto creado por él mismo (como el wr.txt anterior). Este es el escenario que demuestra que el DenyReadForWriter está funcionando.

Reader (solo lectura)

# Deben FUNCIONAR
aws --profile storin-reader s3api get-object --bucket <BUCKET> --key wr.txt /tmp/y.txt
aws --profile storin-reader s3api list-objects-v2 --bucket <BUCKET>

# Deben devolver 403 (AccessDenied)
aws --profile storin-reader s3api put-object --bucket <BUCKET> --key ot.txt --body /tmp/t.txt
aws --profile storin-reader s3api delete-object --bucket <BUCKET> --key wr.txt

Resultado esperado

Identidad	PUT	GET	LIST	DELETE
Propietario	✅	✅	✅	✅
Writer	✅	❌	❌	❌
Reader	❌	✅	✅	❌

🛠️ Troubleshooting – Problemas Comunes

❌ `403 AccessDenied` al aplicar o usar la policy

Verifique que el Principal esté en el formato "CanonicalUser": "<USER_ID>".
Confirme que el User ID copiado sea del proyecto correcto (pestaña Accesos).
Confirme que la policy se haya aplicado con la credencial del propietario del bucket.

❌ `ValidationError` en toda subida (AWS CLI)

Faltan las líneas de checksum en ~/.aws/config. Agréguelas al perfil:

request_checksum_calculation = when_required
response_checksum_validation = when_required

❌ El Writer puede leer sus propios archivos

El bloque DenyReadForWriter no está en la policy o tiene el User ID incorrecto. Revise la policy y aplíquela nuevamente.

❌ La credencial "restringida" tiene acceso total

La Access Key fue generada en el mismo proyecto del propietario del bucket. Las claves del mismo proyecto comparten el mismo User ID. Cree un proyecto separado para el perfil restringido, según la Parte 1.

❌ El Reader no puede listar el bucket

La acción s3:ListBucket necesita los dos resources: arn:aws:s3:::<BUCKET> y arn:aws:s3:::<BUCKET>/*.

Sobre la sobrescritura de objetos

El Writer puede subir un objeto con una clave ya existente, reemplazando el contenido anterior. Si esto representa un riesgo en su caso, use claves únicas en la subida (por ejemplo, con fecha y hora en el nombre) o habilite el versionado en el bucket.

📘 Documentación relacionada: Configurando la AWS CLI con Storin

📌 Visión General​

🧠 Cómo Storin aplica los permisos​

Ejemplo de estructura​

🧰 Requisitos previos​

🆔 Parte 1 – Creando las identidades (User IDs)​

Paso 1 – Crear un nuevo proyecto​

Paso 2 – Inicializar la identidad S3​

Paso 3 – Copiar el User ID​

Paso 4 – Generar la Access Key y la Secret Key​

⚙️ Parte 2 – Configurando la AWS CLI​

Archivo ~/.aws/config​

Archivo ~/.aws/credentials​

📝 Parte 3 – Creando y aplicando la Bucket Policy​

Paso 1 – Crear el archivo de la policy​

Qué hace cada bloque​

Paso 2 – Aplicar la policy​

❗ Reglas obligatorias​

✅ Parte 4 – Validando los permisos​

Writer (solo escritura)​

Reader (solo lectura)​

Resultado esperado​

🛠️ Troubleshooting – Problemas Comunes​

❌ 403 AccessDenied al aplicar o usar la policy​

❌ ValidationError en toda subida (AWS CLI)​

❌ El Writer puede leer sus propios archivos​

❌ La credencial "restringida" tiene acceso total​

❌ El Reader no puede listar el bucket​