Nesta página fornecemos uma visão geral do Gerenciamento de identidade e acesso (IAM, na sigla em inglês) e o respectivo uso com o controle de acesso a recursos como buckets e objetos no Cloud Storage.
Para aprender outras formas de controlar o acesso no Cloud Storage, consulte Visão geral do controle de acesso.
Para ver informações detalhadas sobre o IAM e seus recursos gerais, consulte Gerenciamento de identidade e acesso.
Visão geral
Com o IAM, é possível controlar quem tem acesso aos recursos do projeto do Google Cloud. Esses recursos abrangem os buckets do Cloud Storage e os objetos armazenados neles, além de outras entidades do Google Cloud como instâncias do Compute Engine.
Os Principais são o "quem" do IAM. Eles podem ser usuários individuais, grupos, domínios ou até mesmo o público em geral. Os Principais recebem papéis que permitem executar ações no Cloud Storage e no Google Cloud de maneira geral. Cada papel se baseia em um conjunto de uma ou mais permissões. As permissões são as unidades básicas do IAM: cada uma possibilita executar determinada ação.
Por exemplo, a permissão storage.objects.create
permite criar objetos. Essa permissão é encontrada em papéis como Storage Object Creator, que concede permissões úteis para criar objetos em um bucket, e Storage Object Admin, que concede diversas permissões para trabalhar com objetos.
A coleção de papéis do IAM que você define em um recurso é chamada de política do IAM. O acesso concedido por esses papéis se aplica ao recurso em que a política está definida e aos recursos contidos nesse recurso. Por exemplo, é possível definir uma política do IAM em um bucket que dê ao usuário controle administrativo desse bucket e dos respectivos objetos. Também é possível definir uma política do IAM no projeto geral que dê a outro usuário a capacidade de visualizar objetos em qualquer bucket dentro do projeto.
Permissões
Com as permissões, os Principais podem executar ações específicas em buckets ou objetos no Cloud Storage. Por exemplo, a permissão storage.buckets.list
possibilita ao membro listar os buckets no projeto. Você não concede permissões aos Principais diretamente. Em vez disso, você concede papéis que têm uma ou mais permissões próprias.
Para ver uma lista de referência das permissões de IAM que se aplicam ao Cloud Storage, consulte Permissões do IAM para o Cloud Storage.
Papéis
Papéis são um conjunto de uma ou mais permissões. Por exemplo, o papel de Leitor de objetos do Storage contém as permissões storage.objects.get
e storage.objects.list
. Você concede papéis aos Principais, o que permite que eles realizem ações nos buckets e nos objetos do seu projeto.
Para ver a lista de referência dos papéis de IAM que se aplicam ao Cloud Storage, consulte Papéis do IAM para o Cloud Storage.
Papéis no nível do projeto x papéis no nível do bucket
A concessão de papéis no nível do bucket não afeta os papéis concedidos no nível do projeto e vice-versa. Use esses dois níveis de granularidade para personalizar suas permissões. Por exemplo, digamos que você queira dar a um usuário a permissão para ler objetos em qualquer bucket, mas para criar objetos apenas em um bucket específico. Para isso, conceda ao usuário o papel de Leitor de objetos do Storage no nível do projeto, permitindo que ele leia qualquer objeto armazenado em qualquer bucket no projeto. Depois, conceda o de criador de objetos do Storage no nível do bucket para um bucket específico, permitindo que ele crie objetos somente nesse intervalo.
É possível usar alguns papéis nos níveis do projeto e do bucket. Quando usados no nível do projeto, as permissões que eles têm se aplicam a todos os buckets e objetos no projeto. No nível do bucket, as permissões se aplicam apenas a um bucket específico e aos objetos nele contidos. Administrador do Storage, Leitor de objetos do Storage e criador de objetos do Storage são exemplos desses papéis.
Alguns papéis só podem ser aplicados a um nível. Só é possível aplicar o papel Proprietário do objeto legado do Storage no nível do bucket.
Relação com as ACLs
Os papéis de IAM de bucket legado funcionam acoplados às ACLs do bucket: quando você adiciona ou remove um papel do bucket legado, essas alterações são refletidas nas ACLs associadas a ele. Da mesma forma, a alteração de uma ACL específica do bucket atualiza o papel do IAM do bucket legado correspondente.
Papel do bucket legado | ACL equivalente |
---|---|
Leitor de bucket legado do Storage | Leitor de bucket |
Gravador de bucket legado do Storage | Gravador de bucket |
Proprietário de bucket legado do Storage | Proprietário de bucket |
Todos os outros papéis do IAM no nível do bucket, incluindo os do IAM de objeto legado, funcionam independentemente das ACLs. Da mesma forma, todos os papéis do IAM para envolvidos no projeto funcionam de forma independente das ACLs. Por exemplo, se você fornecer a um usuário o papel Visualizador do objeto de armazenamento, as ACLs não serão alteradas. Isso significa que é possível usar os papéis de IAM no nível de bucket para conceder acesso amplo a todos os objetos de um bucket e usar as ACLs de objeto para personalizar o acesso a objetos específicos do bucket.
Permissão do IAM para alteração de ACLs
Use o IAM para conceder aos Principais a permissão necessária para
alterar as ACLs nos objetos. Juntas, as seguintes permissões de storage.buckets
permitem que os usuários trabalhem com ACLs de bucket e ACLs de objeto padrão: .get
, .getIamPolicy
, .setIamPolicy
e .update
.
Da mesma forma, as seguintes permissões de storage.objects
juntas permitem que os usuários trabalhem com ACLs de objeto: .get
, .getIamPolicy
, .setIamPolicy
e .update
.
Papéis personalizados
O IAM tem muitos papéis predefinidos que abrangem casos de uso comum, mas nada impede que você defina seus papéis e especifique as permissões contidas nos pacotes. Para isso, o IAM oferece papéis personalizados.
Tipos de principais
Há vários tipos diferentes de Principais. As Contas do Google e os Grupos do Google, por exemplo, representam dois tipos gerais, enquanto o allAuthenticatedUsers
e o allUsers
representam dois tipos especializados. Para conseguir uma lista de tipos
de membros típicos no IAM, consulte Conceitos relacionados à identidade.
Valores de conveniência
O Cloud Storage é compatível com valores de conveniência, que são um conjunto especial de principais que podem ser aplicados especificamente às políticas de bucket do IAM. Em geral, evite usar valores de conveniência em ambientes de produção, porque eles exigem a concessão de papéis básicos, uma prática não recomendada em ambientes de produção.
Um valor de conveniência é um identificador de duas partes que consiste em um papel básico e um ID do projeto:
projectOwner:PROJECT_ID
projectEditor:PROJECT_ID
projectViewer:PROJECT_ID
Um valor de conveniência atua como uma ponte entre os Principais que receberam o papel básico e um papel do IAM. O papel do IAM concedido ao valor de conveniência também é, na prática, concedido a todos os Principais do papel básico especificado no ID do projeto especificado.
Por exemplo, digamos que jane@exemplo.com e joao@exemplo.com tenham o papel básico de Leitor
para um projeto chamado my-example-project
e digamos que você tem um bucket nesse
projeto chamado my-bucket
. Se você conceder o papel Criador de objetos do Storage para
my-bucket
ao valor de conveniência projectViewer:my-example-project
,
tanto jane@example.com quanto john@example.com receberão as permissões associadas a
Criador de objetos do Storage para my-bucket
.
É possível conceder e revogar o acesso aos valores de conveniência dos buckets, mas observe que o Cloud Storage os aplica automaticamente em determinadas circunstâncias. Consulte Comportamento modificável para papéis básicos no Cloud Storage para mais informações.
Condições
Condições de IAM permitem que você defina condições que controlam como as permissões são concedidas aos Principais. O Cloud Storage é compatível com os seguintes tipos de atributos de condição:
resource.name
: conceda acesso a buckets e objetos com base no nome de cada um. Também é possível usarresource.type
para conceder acesso a buckets ou objetos, mas fazer isso é praticamente a mesma coisa que usarresource.name
. O exemplo de condição a seguir aplica uma configuração do IAM a todos os objetos com o mesmo prefixo:resource.name.startsWith('projects/_/buckets/BUCKET_NAME/objects/OBJECT_PREFIX')
- Data/hora: define uma data de validade para a permissão.
request.time < timestamp('2019-01-01T00:00:00Z')
Essas expressões condicionais são instruções lógicas que usam um subconjunto do Common Expression Language (CEL). Especifique condições nas vinculações de papel da política de IAM de um bucket.
Lembre-se destas restrições:
- É necessário ativar o acesso uniforme no nível do bucket antes de adicionar condições desse nível. Embora as condições sejam permitidas para envolvidos no projeto, é preciso migrar todos os buckets do projeto para um acesso uniforme no nível do bucket para evitar que as ACLs do Cloud Storage substituam as condições do IAM para envolvidos no projeto. É possível aplicar uma restrição de acesso uniforme no nível do bucket para ativar acesso uniforme no nível do bucket a todos os novos buckets no projeto.
- O comando
gsutil iam ch
não funciona com políticas que contenham condições. Para modificar uma política com condições, usegsutil iam get
para recuperar a política do bucket relevante, editá-la localmente e, em seguida, usargsutil iam set
para aplicá-la novamente ao bucket. - A gsutil precisa estar na versão 4.38 ou superior para usar as condições.
- Ao usar a API JSON para chamar
getIamPolicy
esetIamPolicy
em buckets com condições, você precisa definir a versão da política de IAM para 3. - Como a permissão
storage.objects.list
é concedida no nível do bucket, não é possível usar o atributo da condiçãoresource.name
para restringir o acesso à listagem de objetos para um subconjunto de objetos no bucket. Os usuários sem a permissãostorage.objects.list
no nível do bucket podem ter funcionalidades prejudicadas para o Console e a gsutil. - As condições expiradas permanecem na política de IAM até que você as remova.
Como usar com as ferramentas do Cloud Storage
Ainda que as permissões do IAM não possam ser definidas por meio da API XML, os usuários que tiverem recebido permissões do IAM ainda poderão usar a API XML e qualquer outra ferramenta para acessar o Cloud Storage.
Para saber quais permissões de IAM os usuários podem usar para executar ações com as diferentes ferramentas do Cloud Storage, consulte IAM com o Console do Cloud, IAM com gsutil, IAM com JSON e IAM com XML.
A seguir
- Como usar o IAM com Cloud Storage.
- Revise a tabela de referência do IAM para Cloud Storage.
- Saiba mais sobre as práticas recomendadas para o uso do IAM.
- Gerencie as políticas do IAM para todos os recursos do Google Cloud.