Visão geral do IAM

Nesta página, descrevemos como funciona o sistema do Identity and Access Management (IAM) do Cloud de Confiance by S3NS e como usá-lo para gerenciar o acesso no Cloud de Confiance.

O IAM é uma ferramenta para gerenciar a autorização detalhada do Cloud de Confiance. Em outras palavras, ele permite controlar quem pode fazer o quê em quais recursos.

Acesso em Cloud de Confiance

Toda ação em Cloud de Confiance requer determinadas permissões. Quando alguém tenta realizar uma ação no Cloud de Confiance, por exemplo, criar uma instância de VM ou visualizar um conjunto de dados, o IAM primeiro verifica se a pessoa tem as permissões necessárias. Caso contrário, o IAM impede que eles realizem a ação.

Conceder permissões a alguém no IAM envolve os três componentes a seguir:

  • Principal: a identidade da pessoa ou do sistema a que você quer conceder permissões.
  • Papel: a coleção de permissões que você quer conceder ao principal.
  • Recurso: o recurso Cloud de Confiance que você quer permitir que o principal acesse.

Para conceder permissão ao principal para acessar o recurso, atribua a ele a função no recurso. Você concede esses papéis usando uma política de permissão.

As seções a seguir descrevem esses conceitos em mais detalhes.

Principais

No Cloud de Confiance , você controla o acesso para principais. Os principais representam uma ou mais identidades autenticadas em Cloud de Confiance.

No passado, os principais eram chamados de membros. Algumas APIs ainda usam esse termo.

Há vários tipos de principais no IAM, mas eles podem ser divididos em duas categorias gerais:

  • Usuários humanos: alguns tipos de principais do IAM representam usuários humanos. Você usa esses tipos principais para gerenciar o acesso dos funcionários aos recursos do Cloud de Confiance .

    Por exemplo, as identidades federadas em pools de identidade de colaboradores representam usuários humanos.

  • Cargas de trabalho: alguns tipos de principais do IAM representam cargas de trabalho. Você usa esses tipos principais ao gerenciar o acesso dos recursos Cloud de Confiance das suas cargas de trabalho.

    Os tipos principais que representam cargas de trabalho incluem contas de serviço e identidades federadas em um pool de Identidade da carga de trabalho.

Para mais informações sobre principais, consulte Principais do IAM.

Permissões e papéis

Com as permissões, você determina quais operações são permitidas em um recurso. No IAM, as permissões geralmente são representadas no formato service.resource.verb. Muitas vezes, as permissões têm correspondência de um para um com os métodos da API REST. Por exemplo, a permissão resourcemanager.projects.list permite listar projetos do Resource Manager.

Não é possível conceder permissões diretamente a um principal. Em vez disso, você concede permissões aos principais atribuindo papéis.

Papéis são coleções de permissões. Ao conceder um papel a um principal, você dá a ele todas as permissões desse papel.

Há três tipos de papéis:

  • Papéis predefinidos: papéis gerenciados pelos serviços do Cloud de Confiance . Esses papéis contêm as permissões necessárias para realizar tarefas comuns em cada serviço. Por exemplo, o papel Publicador do Pub/Sub (roles/pubsub.publisher) permite publicar mensagens em um tópico do Pub/Sub.

  • Papéis personalizados: papéis criados por você que contêm apenas as permissões especificadas. Você tem controle total sobre as permissões nesses papéis. No entanto, elas têm um custo de manutenção maior do que as funções predefinidas, e há um limite para o número de funções personalizadas que você pode ter no projeto e na organização.

  • Papéis básicos: papéis altamente permissivos que oferecem acesso amplo aos serviços do Cloud de Confiance . Essas funções podem ser úteis para fins de teste, mas não devem ser usadas em ambientes de produção.

Para mais informações sobre papéis e permissões, consulte Papéis e permissões.

Recursos

A maioria dos serviços Cloud de Confiance tem recursos próprios. Por exemplo, o Compute Engine tem recursos como instâncias, discos e sub-redes.

No IAM, você concede papéis em um recurso. Conceder a um principal um papel em um recurso significa que ele pode usar as permissões desse papel para acessar o recurso.

É possível conceder papéis em um subconjunto de recursos do Cloud de Confiance . Para conferir uma lista completa de recursos em que é possível conceder papéis, consulte Tipos de recursos que aceitam políticas de permissão.

Cloud de Confiance também tem vários recursos de contêiner, incluindo projetos, pastas e organizações. Conceder um papel a um principal em um recurso de contêiner dá ao principal acesso ao recurso de contêiner e aos recursos nesse contêiner. Com esse recurso, é possível usar uma única concessão de função para dar a um principal acesso a vários recursos, incluindo aqueles em que não é possível conceder funções diretamente. Para mais informações, consulte Herança de política nesta página.

Permitir políticas

Você concede papéis aos principais usando políticas de permissão. No passado, essas políticas eram chamadas de políticas do IAM.

Uma política de permissão é um objeto YAML ou JSON anexado a um recurso Cloud de Confiance.

Cada política de permissão tem uma lista de vinculações de papéis que associam papéis do IAM aos principais que recebem esses papéis.

Quando um principal autenticado tenta acessar um recurso, o IAM verifica a política de permissão do recurso para determinar se o principal tem as permissões necessárias. Se o principal estiver em uma vinculação de papel que inclua um papel com as permissões necessárias, ele poderá acessar o recurso.

Para ver exemplos de políticas de permissão e saber mais sobre a estrutura delas, consulte Noções básicas sobre políticas de permissão.

Herança de políticas

Cloud de Confiance tem recursos de contêiner, como projetos, pastas e organizações, que permitem organizar os recursos em uma hierarquia pai-filho. Essa hierarquia é chamada de hierarquia de recursos.

A hierarquia de recursos Cloud de Confiance tem a seguinte estrutura:

  • A organização é o nó raiz na hierarquia.
  • As pastas são filhos da organização ou de outra pasta.
  • Os projetos são filhos da organização ou de uma pasta.
  • Os recursos de cada serviço são descendentes de projetos.

O diagrama a seguir é um exemplo de uma hierarquia de recursos do Cloud de Confiance :

Hierarquia para recursos do IAM.

Se você definir uma política de permissão em um recurso de contêiner, ela também será aplicada a todos os recursos nesse contêiner. Esse conceito é chamado de herança de políticas, porque os recursos descendentes herdam as políticas de permissão dos recursos ancestrais.

A herança de políticas tem as seguintes implicações:

  • É possível usar uma única vinculação de função para conceder acesso a vários recursos. Se você quiser dar a um principal acesso a todos os recursos em um contêiner, conceda a ele uma função no contêiner em vez de nos recursos dele.

    Por exemplo, se você quiser permitir que o administrador de segurança gerencie as políticas de permissão para todos os recursos da organização, conceda a ele o papel de Administrador de segurança (roles/iam.securityAdmin) na organização.

  • Você pode conceder acesso a recursos que não têm políticas de permissão próprias. Nem todos os recursos aceitam políticas de permissão, mas todos herdam políticas de permissão dos ancestrais. Para dar a uma principal acesso a um recurso que não pode ter uma política de permissão própria, conceda a ela um papel em um dos ancestrais do recurso.

    Por exemplo, imagine que você quer dar a alguém permissão para gravar registros em um bucket de registros. Os buckets de registros não têm políticas de permissão próprias. Para conceder a alguém essa permissão, atribua a função de gravador de bucket de registros (roles/logging.bucketWriter) no projeto que contém o bucket de registros.

  • Para entender quem pode acessar um recurso, também é necessário conferir todas as políticas de permissão que afetam o recurso. Para conferir uma lista completa dos principais que têm acesso ao recurso, consulte a política de permissão do recurso e as políticas de permissão dos ancestrais dele. A união de todas essas políticas é chamada de política de permissão efetiva.

Para mais informações sobre a herança de políticas de permissão, consulte Como usar a hierarquia de recursos para controle de acesso.

Controle de acesso avançado

Além das políticas de permissão, o IAM oferece os seguintes mecanismos de controle de acesso para ajudar você a refinar quem tem acesso a quais recursos:

  • Políticas de negação: impedem que os principais usem determinadas permissões, mesmo que tenham recebido um papel com a permissão. Para saber mais sobre políticas de negação, consulte Políticas de negação.

  • Condições do IAM: com as condições do IAM, é possível definir e aplicar o controle de acesso condicional baseado em atributos. É possível usar condições em vários tipos de políticas. Por exemplo, é possível adicionar uma condição a uma vinculação de função em uma política de permissão para garantir que a função só seja concedida se a condição for atendida.

    É possível gravar condições com base em atributos como o recurso na solicitação e o horário da solicitação.

    Para saber mais sobre as condições do IAM, consulte Visão geral das condições do IAM.

Modelo de consistência para a API IAM

A API IAM tem consistência eventual. Em outras palavras, se você gravar dados com a API IAM e ler imediatamente esses dados, a operação de leitura poderá retornar uma versão mais antiga dos dados. Além disso, as alterações feitas podem demorar um pouco para afetar as verificações de acesso.

Esse modelo de consistência afeta o funcionamento da API IAM. Por exemplo, se você criar uma conta de serviço e se referir imediatamente a ela em outra solicitação, a API IAM poderá informar que a conta de serviço não foi encontrada. Esse comportamento ocorre porque as operações têm consistência posterior e pode levar algum tempo para que a nova conta de serviço se torne visível para solicitações de leitura.

A seguir