Skip to main content
O armazenamento é dois serviços sob um nome, e eles são protegidos de forma diferente. Volumes e snapshots são controlados apenas pelo IAM. Os buckets e objetos são controlados pelo IAM e pela própria política do bucket, e ambos podem decidir uma solicitação.
A referência da API mostra a ação na página própria de cada endpoint. Ambos vêm do mesmo lugar: a chamada de autorização no serviço, lida no momento da compilação.

​
Volumes, snapshots e políticas

Eles seguem os nomes dos endpoints e o recurso é o CRN do volume, snapshot ou política em que está sendo executada a ação.

​
Buckets e objetos

O lado do objeto recebe seus nomes de ação do S3, então vários deles não correspondem ao endpoint que eles protegem. Estes são os que vale a pena ler antes de escrever uma política.

​
Quatro coisas que os nomes não dizem

Listagem de objetos precisa storage:ListBucket, não um ListObjects ação. A mesma ação abrange a listagem de versões de objetos e a listagem de uploads de várias partes.Esta é a nomenclatura do S3: a ação é nomeada para a coisa que você está listando dentro, não para o que vem de volta. Listar seus buckets é storage:ListAllMyBuckets. Ele é verificado contra a conta, então não pode ser escopo para buckets particulares — conceder isso permite que um chamador veja que cada bucket existe, e nada mais. Remover um sub-recurso de bucket leva a ação Put, não uma ação de exclusão.DELETE /v1/buckets/{bucket}/cors requer storage:PutBucketCORS; o mesmo vale para ciclo de vida, criptografia, marcação e bloqueio de objetos. Limpar uma configuração é escrevê-la para vazia. DELETE em uma chave de objeto tem duas respostas. Apagar o objeto precisa de storage:DeleteObject, mas DELETE /v1/buckets/{bucket}/objects/{key}?tagging — que remove as tags do objeto e deixa o objeto — precisa de storage:PutObject. Remover tags é uma mutação do objeto, não uma exclusão dele. Uma credencial concedida storage:DeleteObject sozinha encontrará o formulário de marcação recusado.

​
Duas camadas no lado do objeto

Cada solicitação de objeto é decidida pelo IAM e pela política de bucket, nesta ordem:
1

Chamadas de anônimos

A política do bucket decide sozinha. Sem política, não há acesso.
2

Chamadas de clientes autenticados

Um deny explícito em qualquer camada recusa a solicitação de forma direta. Caso contrário, um allow explícito de qualquer camada é suficiente para prosseguir. Sem nenhuma das duas, a solicitação é recusada — uma negação implícita.
A política de bucket é a camada que alcança os principais fora da sua conta, incluindo os anônimos. O IAM não pode conceder ao principal de outra pessoa; a política de bucket pode. Os CRNs de principal de máquina incluem o identificador de conta e o UUID de identidade imutável: crn:iam::<account-handle>:role/<role-uuid> ou crn:iam::<account-handle>:service-account/<service-account-uuid>. Use a identidade principal imutável, não o CRN de recurso da função que contém seu nome. Os usuários usam CRNs de usuário qualificados pela organização do Workspace. Os grupos não são solicitações de diretores. O acesso de bucket entre contas ou entre organizações também requer a própria política de conta do principal para permitir a ação. Uma política de bucket não é uma maneira de assumir uma função em outra organização. Negações explícitas permanecem efetivas.
Uma política de bucket que permite anônimos storage:GetObject publica esses objetos na internet. Não há nenhuma segunda opção por trás dela — a política é a opção.
Ambas as camadas param de se aplicar no momento em que a organização do proprietário do bucket é suspensa, incluindo os concessor de contas cruzadas e leitores anônimos.

​
Recursos

Os CRNs de armazenamento são baseados em nome e contêm a região e a conta:
O CRN de um objeto é o do bucket com a chave anexada, então uma política pode ter escopo para um prefixo — bucket/reports/2026/* — da mesma forma que tem escopo para uma convenção de nomeação em volumes: crn:storage:*:my-account:volume/prod-*.

​
Condições

Volumes, snapshots e políticas tomam um mapa de tags, e ambas as chaves de contexto de tag se aplicam:
  • basalt:RequestTag/<key> — o que um chamador pode rotular um recurso como, que é o que torna uma criação autorizada antes que o recurso exista.
  • basalt:ResourceTag/<key> — quais recursos existentes uma ação pode tocar.
Os objetos carregam seus próprios nomes, nomeados para S3 em vez de para nós:
  • s3:RequestObjectTag/<key> — o que uma escrita está tentando definir.
  • s3:ExistingObjectTag/<key> — o que já está no objeto.
  • basalt:TagKeys — o conjunto de chaves de tag que uma requisição carrega.
Apenas volumes de produção, cercados na etiqueta em vez do nome:
Um serviço que lê um prefixo e não escreve nada:
Ambas as linhas de recursos são necessárias. bucket/reports não cobre os objetos dentro dele — o CRN de um objeto é um caminho mais longo, e uma correspondência de curinga pára no recurso que ele nomeia. storage:ListBucket é verificado contra o bucket, storage:GetObject contra o objeto.
Veja writing policies para o formato do documento e cada operador de condição.

​
Como é uma negação

Uma verificação falhada responde 403:
Ele não diz qual ação estava faltando, deliberadamente. Procure a chamada que você fez nas tabelas acima, e a ação que ela precisa é a que você adiciona.
As solicitações no endpoint do protocolo S3 respondem no próprio formato de erro do S3, em vez deste — consulte os códigos de erro do S3. A decisão é a mesma, só o envelope é diferente.