Skip to main content
El almacenamiento es dos servicios bajo un mismo nombre, y se protegen de manera diferente. Los volúmenes y las instantáneas están controlados únicamente por IAM. Los depósitos y objetos están controlados por IAM y por la propia política del depósito, y cualquiera de ellos puede decidir una solicitud.
La referencia de la API muestra la acción en la página propia de cada punto final. Ambos provienen del mismo lugar: la llamada de autorización en el servicio, leída en el momento de la compilación.

​
Volúmenes, instantáneas y políticas

Estos siguen a sus nombres de extremo, y el recurso es el CRN del volumen, instantánea o política sobre la que se está actuando.

​
Buckets y objetos

El lado de objeto toma sus nombres de acción de S3, por lo que varios de ellos no coinciden con el punto final que protegen. Estos son los que vale la pena leer antes de escribir una política.

​
Cuatro cosas que los nombres no te dicen

Listado de objetos que necesita storage:ListBucket, no un ListObjects acción. La misma acción cubre la lista de versiones de objetos y la lista de cargas de múltiples partes.Este es el nombre de S3: la acción se llama por la cosa que estás listando dentro, no por lo que viene de vuelta. Listar tus depósitos es storage:ListAllMyBuckets. Se comprueba con la cuenta, por lo que no puede ser ampliado a depósitos particulares — concederlo permite a un llamador ver que cada depósito existe, y nada más. Eliminar un sub-recurso de bucket toma la acción Put, no una acción de eliminación.DELETE /v1/buckets/{bucket}/cors requiere storage:PutBucketCORS; lo mismo se aplica para el ciclo de vida, el cifrado, el etiquetado y el bloqueo de objetos. Borrar una configuración es escribirla en vacío. DELETE en una clave de objeto tiene dos respuestas. Eliminar el objeto necesita storage:DeleteObject, pero DELETE /v1/buckets/{bucket}/objects/{key}?tagging — que elimina las etiquetas del objeto y deja el objeto — necesita storage:PutObject. Eliminar etiquetas es una mutación del objeto, no una eliminación de él. Una credencial concedida storage:DeleteObject solo encontrará el formulario de etiquetado rechazado.

​
Dos capas en el lado del objeto

Cada solicitud de objeto es decidida por IAM y por la política de depósito, en este orden:
1

Llamantes anónimos

La política del bucket decide por sí sola. Sin política no hay acceso.
2

Llamantes autenticados

Un deny explícito en cualquiera de las capas rechaza la solicitud de manera directa. Si no es así, un allow explícito de cualquiera capa es suficiente para continuar. Sin ninguno de los dos, la solicitud es rechazada — una denegación implícita.
La política de depósito es la capa que llega a los principales fuera de su cuenta, incluidos los anónimos. IAM no puede conceder a otro principal; la política de depósito sí puede. Los CRN de los principales de la máquina incluyen el identificador de cuenta y el UUID de identidad inmutable: crn:iam::<account-handle>:role/<role-uuid> o crn:iam::<account-handle>:service-account/<service-account-uuid>. Utilice la identidad principal inmutable, no el CRN de recurso del rol que contiene su nombre. Los usuarios utilizan CRN de usuario calificados por la organización de Workspace. Los grupos no son solicitantes principales. El acceso a depósitos entre cuentas o entre organizaciones también requiere que la propia directiva de cuenta del principal permita la acción. Una política de depósito no es una forma de asumir un rol en otra organización. Las negaciones explícitas siguen siendo efectivas.
Una política de bucket que permite el uso anónimo storage:GetObject Publica esos objetos en Internet. No hay un segundo interruptor detrás de él: la política es el interruptor.
Ambas capas dejan de aplicarse en el momento en que se suspende la organización del propietario del depósito, incluidos los concesionarios de cuentas cruzadas y los lectores anónimos.

​
Recursos

Los CRN de almacenamiento se basan en el nombre y llevan la región y la cuenta:
El CRN de un objeto es el del bucket con la clave anexada, por lo que una política puede tener un alcance a un prefijo — bucket/reports/2026/* — de la misma manera que tiene un alcance a una convención de nombres en volúmenes: crn:storage:*:my-account:volume/prod-*.

​
Condiciones

Los volúmenes, las instantáneas y las políticas toman un mapa de tags, y se aplican ambas claves de contexto de etiquetas:
  • basalt:RequestTag/<key> — lo que un llamador puede etiquetar un recurso como, que es lo que hace que una creación sea autorizable antes de que el recurso exista.
  • basalt:ResourceTag/<key> — los recursos existentes que una acción puede tocar.
Los objetos llevan su propio nombre, nombrado para S3 en lugar de para nosotros:
  • s3:RequestObjectTag/<key> — lo que una escritura está tratando de establecer.
  • s3:ExistingObjectTag/<key> — lo que ya está en el objeto.
  • basalt:TagKeys — el conjunto de claves de etiquetas que lleva una solicitud.
Solo volúmenes de producción, cercados en la etiqueta en lugar del nombre:
Un servicio que lee un prefijo y no escribe nada:
Se necesitan ambas líneas de recursos. bucket/reports no cubre los objetos dentro de él — el CRN de un objeto es una ruta más larga, y una coincidencia de comodín se detiene en el recurso que nombra. storage:ListBucket se comprueba contra el bucket, storage:GetObject contra el objeto.
Consulte writing policies para el formato del documento y cada operador de condición.

​
Qué aspecto tiene una negación

Una comprobación fallida responde 403:
No te dice qué acción faltaba, deliberadamente. Busca la llamada que hiciste en las tablas anteriores, y la acción que necesita es la que se debe agregar.
Las solicitudes en el punto final del protocolo S3 responden en el propio formato de error de S3 en lugar de este. Consulta los códigos de error de S3. La decisión es la misma, solo el sobre difiere.