Como compreender os papéis personalizados do IAM

Enviar feedback sobre os papéis personalizados Beta

Com os papéis predefinidos do Google Cloud Identity & Access Management (Cloud IAM), é possível ter acesso granular a recursos específicos do Google Cloud Platform. Além disso, você pode impedir o acesso indesejado a outros recursos.

Com o Cloud IAM, você também cria papéis personalizados com uma ou mais permissões, além de poder atribuir esses papéis a usuários da sua organização. Uma IU e uma API são fornecidas para criar e gerenciar esses papéis.

Neste tópico, não há uma lista abrangente de todas as permissões do Cloud IAM que você pode incluir nos papéis personalizados. Saiba mais sobre as permissões que podem ser aplicadas a um serviço específico usando os links da seção Outras documentações do IAM.

Antes de começar

Conceitos básicos

Não conceda permissões diretamente aos usuários. Em vez disso, atribua a eles papéis que agrupem uma ou mais permissões. Os papéis predefinidos são criados pelo Google e mantidos com as permissões mais atualizadas necessárias para os novos recursos e outras alterações. Com os papéis personalizados, agrupe as permissões disponíveis para atender às suas necessidades. Esse papel pode ser criado tanto no nível de organização quanto no de projeto.

Para criar um papel personalizado, combine uma ou mais permissões do Cloud IAM. Com elas, os usuários executam ações específicas nos recursos do Google Cloud Platform. No Cloud IAM, essas permissões são representadas no seguinte formato:

`<service>.<resource>.<verb>`

Por exemplo, com a permissão compute.instances.list, um usuário lista as instâncias do Google Compute Engine que pertencem a ele. Ao mesmo tempo, a compute.instances.stop possibilita que um usuário pare uma máquina virtual (VM, na sigla em inglês).

Geralmente, a correspondência entre as permissões e os métodos REST é de 1:1. Ou seja, cada serviço do GCP tem um conjunto de permissões associado para cada método REST que ele tem. Para chamar um método, o autor da chamada precisa dessas permissões. Por exemplo, para o topic.publish(), é necessária a permissão pubsub.topics.publish.

Só é possível criar papéis personalizados a serem usados em todo o projeto ou organização. Isso não pode ser feito no nível da pasta.

Use os papéis personalizados somente para conceder permissões a políticas do projeto ou da organização aos quais os papéis ou recursos pertencem. Isso não pode ser feito se um recurso pertence a um projeto ou organização diferente.

Permissões e papéis obrigatórios

Para criar um papel personalizado, o autor da chamada precisa ter a permissão iam.roles.create.

Os usuários que não são proprietários, inclusive os administradores da organização, precisam ter o papel de Administrador de papéis da organização ou de Administrador de papéis de IAM. Com o papel de Revisor de segurança do IAM, roles/iam.securityReviewer, é possível ver os papéis personalizados, mas não administrá-los.

A interface do usuário dos papéis personalizados está no Console do Cloud Platform, em "Papéis de IAM". Ela só fica disponível para usuários que têm permissões para criar ou gerenciar esses papéis. Por padrão, somente proprietários de projeto criam novos papéis. Para controlar o acesso a esses recursos, os proprietários atribuem o papel de Administrador de papéis de IAM a outros membros do mesmo projeto. No caso das organizações, somente os Administradores da organização atribuem o papel de Administrador de papéis da organização.

Os papéis administrativos estão descritos com mais detalhes abaixo.

Administrador de papéis da organização

Se você tem uma organização associada à sua conta do GCP, com o papel de Administrador de papéis da organização é possível administrar todos os papéis personalizados da sua organização. Esse papel só pode ser atribuído no nível da organização e somente Administradores da organização podem concedê-lo.

Na tabela abaixo, você tem uma lista das permissões desse papel:

Papel Permissões
roles/iam.organizationRoleAdministrator iam.roles.create
iam.roles.delete
iam.roles.undelete
iam.roles.get
iam.roles.getIamPolicy
iam.roles.setIamPolicy
iam.roles.list
iam.roles.update
resourcemanager.projects.get
resourcemanager.projects.getIamPolicy
resourcemanager.projects.list
resourcemanager.organizations.get
resourcemanager.organizations.getIamPolicy

Administrador de papéis de IAM

Com o papel de Administrador de papéis do IAM, você consegue administrar todos os papéis personalizados de um projeto. Use esse papel, caso não tenha uma organização. Ele só pode ser atribuído no nível do projeto.

Na tabela abaixo, você tem uma lista das permissões desse papel:

Papel Permissões
roles/iam.roleAdmin iam.roles.create
iam.roles.delete
iam.roles.undelete
iam.roles.get
iam.roles.list
iam.roles.update
iam.roles.getIamPolicy
iam.roles.setIamPolicy
resourcemanager.projects.get
resourcemanager.projects.getIamPolicy

Ciclo de vida dos papéis personalizados

Há alguns conceitos que se aplicam na hora de decidir como você pretende modelar, criar e gerenciar os papéis personalizados.

Criação

Antes de criar um papel personalizado, verifique se já não há um papel predefinido no serviço, ou um conjunto deles, que atenda às suas necessidades. Saiba mais sobre permissões aplicáveis a um serviço específico usando os links da seção Outras documentações do IAM. Para uma lista das permissões de um determinado papel, consulte Como consultar os metadados do papel.

Se o conjunto de permissões concedidas a um ou mais papéis predefinidos não estiver adequado para você, crie um papel personalizado com base nos predefinidos e adicione ou exclua permissões, conforme a necessidade. Os detalhes de como fazer isso estão em Como criar e gerenciar papéis personalizados.

Esteja ciente de que algumas permissões talvez não estejam visíveis ou não possam ser usadas em um papel personalizado. Por exemplo, isso pode acontecer quando o serviço está na versão Beta ou você não ativou a API para o serviço.

Dependências da permissão

Algumas permissões só são eficazes quando concedidas em pares. Por exemplo, para atualizar as políticas do IAM, é necessário usar o padrão leitura-modificação-gravação. Quase sempre, setIamPolicy requer o uso de getIamPolicy. Assim, você recebe o etag antes de atualizar a política.

Além disso, para garantir que o Google Cloud Console funcione conforme o esperado, conceda as permissões resourcemanager.projects.get e resourcemanager.projects.list nos níveis apropriados. Em geral, a permissão de listar é concedida ao recurso pai e a de receber ao recurso filho.

Nomear o papel

O código do papel personalizado precisa ser exclusivo, mas isso não é necessário para a propriedade de nome.

Isso significa que mais de um papel personalizado com o mesmo nome podem ser exibidos no console. Para evitar confusões, use nomes exclusivos e descritivos nos seus papéis.

Escolha o código do papel com cuidado, já que ele não pode ser alterado. Você pode excluir um papel, mas não é possível criar um papel novo personalizado com o mesmo código até que o processo de exclusão de 37 dias tenha sido concluído. Para mais informações sobre o processo de exclusão, consulte Como excluir um papel personalizado.

O nome do papel é aquele exibido no console. Escolha nomes não ambíguos para evitar que os usuários se confundam quando selecionarem papéis personalizados no console. Além disso, é recomendável indicar quais papéis são da organização e quais são do projeto. Para isso, inclua essa informação no nome. Ele pode ser alterado a qualquer momento.

Descrição do papel

Depois de editar um papel personalizado, sempre atualize a descrição dele. Inclua, no mínimo, a data em que ele foi modificado e um resumo descritivo desse papel.

Testar e implantar

Os papéis personalizados incluem uma propriedade role.stage. Inicialmente, defina o estágio como ALPHA para indicar que o papel está em uma fase inicial do desenvolvimento e não está pronto para produção. Em seguida, conceda a permissão para um pequeno conjunto de membros da organização usar o papel em alguns casos de uso de amostra.

Quando os membros estiverem satisfeitos com o papel personalizado recém-criado, altere a propriedade role.stage para BETA ou GA. Em geral, se o papel faz referência a permissões de serviços que estão na versão Beta, é preciso marcá-lo como BETA e não GA, até que eles não estejam mais nessa versão.

Em manutenção

As funções de tarefa e funcionalidades do produto estão em constante evolução. A atualização e a atribuição dos papéis personalizados com o mínimo de privilégios necessários requer um esforço de manutenção.

Por exemplo, quando um serviço é lançado com novos recursos de versão Beta, os métodos da API ficam disponíveis publicamente e as permissões são adicionadas automaticamente aos respectivos papéis primitivos e predefinidos. Os papéis personalizados do serviço não herdam essas novas permissões. Isso significa que os usuários que têm esses papéis atribuídos podem relatar que não conseguem acessar esses recursos. Há duas possibilidades: adicioná-los ou talvez criar um papel separado somente para conceder esse acesso a determinados usuários.

Quando o Google atualiza um papel predefinido, adicionando ou removendo permissões, os papéis personalizados baseados nesse papel não são modificados. Papéis personalizados são listas simples de permissões, não há um vínculo com os predefinidos que deram origem a eles.

É recomendável que esse tipo de informação seja adicionado ao campo "Descrição". Desse modo, fica mais fácil decidir se as alterações mais recentes nos papéis predefinidos justificam as atualizações. Essas informações são adicionadas automaticamente à "Descrição" quando o papel personalizado é criado no Cloud Console.

Consulte o Registro de alterações de permissões do IAM para ver quais permissões foram alteradas recentemente.

Como desativar papéis personalizados

Se você quer que as pessoas da organização não usem mais o papel, altere a propriedade role.stage dela para DEPRECATED e, se preferir, configure a deprecation_message para que os usuários sejam informados sobre os papéis alternativos que precisam ser usados ou onde encontrar mais informações. Além disso, confira se você não tem políticas que façam referência a esse papel.

Chame roles:UpdateRole() quando tiver certeza de que o papel foi desativado.

Restrições da versão Beta

Expectativas de confiabilidade

  • Esta é uma versão Beta. Ela é adequada para testar suas funções personalizadas com as combinações específicas de permissões que atendem às suas necessidades. Cada serviço determina o preparo do sistema para aceitar papéis personalizados. Consulte o Registro de alterações de permissões do IAM para descobrir quais permissões foram alteradas para um determinado serviço.

Problemas conhecidos

  • Alguns papéis predefinidos têm permissões com uso suspenso ou que não são permitidas em papéis personalizados. Um papel personalizado baseado em um predefinido com essas características não contém essas permissões.

  • Outros projetos não podem ser listados por papéis personalizados criados dentro de um projeto. Quando você copia um papel predefinido que inclui a permissão resourcemanager.projects.list em um novo papel personalizado, essa permissão é removida e a seguinte mensagem é exibida:

    • Console do Cloud Platform: Permissões proibidas
    • Ferramenta de linha de comando gcloud do Cloud SDK: not valid

Próximas etapas

Outras documentações do IAM

Documentação Descrição
Visão geral do IAM Explicação dos conceitos básicos do IAM
Como entender os papéis Explicação dos papéis do IAM primários e predefinidos
IAM para organizações Explicação dos papéis e das permissões do IAM para organizações
IAM para projetos Explicação dos papéis e das permissões do IAM para projetos
IAM para o App Engine Explicação dos papéis e das permissões do IAM para o App Engine
IAM para o Compute Engine Explicação dos papéis e das permissões do IAM para o Compute Engine.
IAM para o Cloud Storage Explicação dos papéis e das permissões do IAM para o Google Cloud Storage
IAM para o Cloud BigQuery Explicação dos papéis e das permissões do IAM para o Cloud BigQuery
IAM para o Cloud Bigtable Explicação dos papéis e das permissões do IAM para o Cloud BigTable
IAM para o Stackdriver Logging Explicação dos papéis e das permissões do IAM para o Stackdriver Logging
IAM para o Cloud Pub/Sub Explicação dos papéis e das permissões para o Cloud Pub/Sub
IAM para o Cloud Dataflow Explicação dos papéis e das permissões do IAM para o Cloud Dataflow
IAM para o Stackdriver Debugger Explicação dos papéis e das permissões do IAM para o Stackdriver Debugger
IAM para o Cloud Deployment Manager Explicação dos papéis e das permissões do IAM para o Cloud Deployment Manager
IAM para o Cloud Datastore Explicação dos papéis e das permissões do IAM para o Cloud Datastore
Observação: o Cloud Datastore atualmente não é compatível com os papéis personalizados.
IAM para o Cloud Dataproc Explicação dos papéis e das permissões do IAM para o Cloud Dataproc
IAM para Kubernetes Engine Explicação dos papéis e permissões do IAM para o Kubernetes Engine
IAM para o Cloud DNS Explicação dos papéis e das permissões do IAM para o Cloud DNS
IAM para pastas Explicação dos papéis e permissões do IAM para pastas
IAM para o Google Genomics Explicação dos papéis e das permissões do IAM para o Google Genomics
IAM para o Stackdriver Trace Explicação dos papéis e das permissões do IAM para o Stackdriver Trace
IAM para a Cloud Billing API Explicação dos papéis e das permissões do IAM para a Cloud Billing API
IAM para o Service Management Explicação dos papéis e das permissões do IAM para o Service Management
Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Documentação do Cloud Identity and Access Management