Identity and Access Management

Uso

Nesta página, você acessa as informações gerais do Identity and Access Management (IAM) e do uso dele no controle de acesso a buckets, pastas gerenciadas e recursos de objetos no Cloud Storage.

Visão geral

Com o IAM, é possível controlar quem tem acesso aos recursos do projeto do Google Cloud. Os recursos incluem buckets do Cloud Storage, as pastas gerenciadas neles e os objetos armazenados nos buckets, 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. Com cada uma delas, é possível executar uma determinada ação.

Por exemplo, a permissão storage.objects.create permite criar objetos. Essa permissão é encontrada em papéis como (roles/storage.objectCreator) Storage Object Creator, que concede permissões úteis para criar objetos em um bucket, e Storage Object Admin (roles/storage.objectAdmin), 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.

Se você tiver um recurso da organização do Google Cloud, também poderá usar políticas de negação de IAM para negar acesso a recursos. Quando uma política de negação é anexada a um recurso, o principal da política não pode usar a permissão especificada para acessar o recurso ou qualquer sub-recurso dentro dele, independentemente dos papéis concedidos. As políticas de negação substituem qualquer política de permissão do IAM.

Permissões

Com as permissões, os participantes podem executar ações específicas em buckets, pastas gerenciadas 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 (roles/storage.objectViewer) 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, pastas gerenciadas 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.

Como conceder papéis no nível do projeto, do bucket ou da pasta gerenciada

Você pode conceder papéis aos principais no nível do projeto, do bucket ou da pasta gerenciada. As permissões concedidas por esses papéis são aplicadas em toda a hierarquia de recursos. É possível conceder papéis em diferentes níveis da hierarquia de recursos para ter mais granularidade no modelo de permissões.

Por exemplo, digamos que você queira dar permissão ao usuário para ler objetos em qualquer bucket de um projeto, mas criar objetos somente no bucket A. Para isso, conceda ao usuário o papel de Leitor de objetos do Storage (roles/storage.objectViewer) para o projeto, o que permite que o usuário leia qualquer objeto armazenado em qualquer bucket do projeto. O papel Criador de objetos do Storage (roles/storage.objectCreator) para o bucket A, que permite ao usuário criar objetos somente nesse bucket.

Alguns papéis podem ser usados em todos os níveis da hierarquia de recursos. Quando usados no nível do projeto, as permissões que eles têm se aplicam a todos os buckets, pastas e objetos no projeto. No nível do bucket, as permissões se aplicam apenas a um bucket específico, pastas e aos objetos nele contidos. Alguns exemplos são os papéis de Administrador do Storage (roles/storage.admin), de Leitor de objetos do Storage (roles/storage.objectViewer) e de Criador de objetos do Storage (roles/storage.objectCreator).

Alguns papéis só podem ser aplicados a um nível. Por exemplo, o papel de Proprietário do objeto legado do Storage (roles/storage.legacyObjectOwner) só pode ser aplicado no nível do bucket ou da pasta gerenciada. Os papéis do IAM que permitem controlar as políticas de negação de IAM só podem ser aplicados no nível da organização.

Relação com as ACLs

Além do IAM, seus buckets e objetos podem usar um sistema de controle de acesso legado chamado listas de controle de acesso (ACLs) se o recurso de acesso uniforme no nível do bucket não estiver ativado para seu bucket. Em geral, evite usar ACLs e ative o acesso uniforme no nível do bucket para seu bucket. Esta seção discute o que você precisa ter em mente se permitir o uso de ACLs para um bucket e os objetos dentro dele.

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 (roles/storage.legacyBucketReader) Leitor do bucket
Gravador de bucket legado do Storage (roles/storage.legacyBucketWriter) Escritor do bucket
Proprietário de bucket legado do Storage (roles/storage.legacyBucketOwner) Proprietário do 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 de Leitor do objeto de armazenamento (roles/storage.objectViewer), as ACLs não serão alteradas.

Como as ACLs de objeto funcionam de forma independente dos papéis do IAM, elas não aparecem na hierarquia das políticas do IAM. Ao avaliar quem tem acesso a um de seus objetos, lembre-se de verificar as ACLs para o objeto, além de verificar as políticas de IAM no nível do projeto e do bucket.

Políticas de negação de IAM x ACLs

As políticas de negação do IAM se aplicam ao acesso concedido pelas ACLs. Por exemplo, se você criar uma política de negação que nega um principal a permissão storage.objects.get em um projeto, o principal não pode ver objetos nesse projeto, mesmo que receba a permissão READER para objetos individuais.

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 ver uma lista de tipos de principais no IAM, consulte Identificadores de principais. Para mais informações sobre principais em geral, 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 (roles/viewer) 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(roles/storage.objectCreator) 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

As Condições do IAM permitem definir condições que controlam como as permissões são concedidas ou negadas aos principais. O Cloud Storage é compatível com os seguintes tipos de atributos de condição:

  • resource.name: conceda ou negue acesso a buckets e objetos com base no bucket ou no nome do objeto. Também é possível usar resource.type para conceder acesso a buckets ou objetos, mas fazer isso é praticamente a mesma coisa que usar resource.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.
  • Ao usar a API JSON para chamar getIamPolicy e setIamPolicy 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ção resource.name para restringir o acesso à listagem de objetos para um subconjunto de objetos no bucket.
  • 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 Referências de IAM para o Cloud Storage.

A seguir