É possível conceder acesso a Google Cloud recursos usando políticas de permissão, que são anexadas aos recursos. É possível anexar apenas uma política a cada recurso. A política de permissão controla o acesso ao próprio recurso e todos os descendentes desse recurso que herdam a política.
Esta página mostra as políticas de permissão no formato JSON. Também é possível usar a Google Cloud CLI para recuperar políticas de permissão em formato YAML.
Estrutura da política
Uma política de permissão é um conjunto de vinculações de papéis e metadados. Uma vinculação de papel especifica qual acesso precisa ser concedido a um recurso. Ela associa (ou vincula) um ou mais principais a um único papel de IAM e qualquer condição específica do contexto que altere como e quando o papel é concedido. Os metadados incluem informações extras sobre a política de permissão, como ETag e versão, para facilitar o gerenciamento de políticas.
Cada vinculação de papel pode incluir os seguintes campos:
- Um ou mais principais, também conhecidos como membros ou identidades. Há vários tipos de principais, incluindo usuários individuais, grupos de usuários e contas de serviço. Para ver uma lista completa dos tipos de principais compatíveis, consulte Tipos de principais.
- Um papel, que é um conjunto nomeado de permissões que oferecem a capacidade de executar ações nos recursos do Google Cloud.
Uma condição, que é uma expressão lógica opcional que restringe ainda mais a vinculação do papel com base em atributos sobre a solicitação, como a origem ou o recurso de destino. As condições normalmente são usadas para controlar se o acesso é concedido com base no contexto de uma solicitação.
Se uma vinculação de papel também incluir uma condição, ela será referenciada como vinculação condicional de papel.
Alguns serviços do Google Cloud não aceitam condições nas políticas de permissão. Para ver uma lista de serviços e tipos de recursos que aceitam condições, consulte Tipos de recursos que aceitam vinculações condicionais de papéis.
As mudanças no acesso de um principal são consistentes posteriores. Isso significa que leva algum tempo para que as mudanças no acesso se propaguem pelo sistema. Para saber quanto tempo leva, em média, para as alterações de acesso propagadas, consulte Acesso à propagação de mudança.
Limites para todos os principais
Cada política de permissão pode conter até
1.500 principais.
Para esse limite, o IAM conta todas as aparências de cada
principal nas vinculações de papéis da política de permissão, bem como nos principais que a política de permissão
isenta da geração de registros de auditoria de acesso a dados. Ele não elimina participantes duplicados que aparecem em mais de uma vinculação
de papel. Por exemplo, se uma política de permissão contiver apenas vinculações de papéis para o principal e este principal aparecer em 50 vinculações de papéis, será possível adicionar mais 1.450 principais às vinculações de papéis na política de permissão.
Além disso, para os fins desse limite, cada aparição de um conjunto principal é contabilizada como um só principal, independentemente do número de participantes individuais no conjunto.
Se você usar as Condições do IAM ou conceder papéis a muitos principais com identificadores longos, pode ser que o IAM permita menos principais na política.
Metadados da política
Os metadados de uma política de permissão incluem os campos a seguir:
- Um campo
etag, usado para controle de simultaneidade e garantir que as políticas de permissão sejam atualizadas de modo consistente. Para mais detalhes, consulte Como usar ETags em uma política nesta página. - Um campo
version, que especifica a versão do esquema de uma determinada política de permissão. Para mais detalhes, consulte Versões da política nesta página.
Para organizações, pastas, projetos e contas de faturamento, a política de permissão também pode conter um campo auditConfig, que especifica os tipos de atividade que geram registros de auditoria para cada serviço. Para saber como configurar essa parte de uma política de permissão, consulte Como configurar registros de auditoria de acesso a dados.
Como usar ETags em uma política
Quando vários sistemas tentam gravar na mesma política de permissão ao mesmo tempo, há um risco de que esses sistemas substituam as alterações uns dos outros. Esse risco existe porque as políticas de permissão são atualizadas usando o padrão ler-modificar-gravar, que envolve várias operações:
- Leitura da política de permissão atual
- Modificação da política de permissão
- Gravação de toda a política de permissão
Se o Sistema A ler uma política de permissão e o Sistema B gravar imediatamente uma versão atualizada dessa política, o Sistema A não reconhecerá as alterações do Sistema B. Quando o Sistema A grava as próprias alterações na política de permissão, as alterações do Sistema B podem ser perdidas.
Para evitar esse problema, o Identity and Access Management (IAM) é compatível com o controle de
simultaneidade com o uso de um campo etag na política de permissão. Cada política de permissão contém um campo de etag, e o valor desse campo muda sempre após uma atualização. Se uma política de permissão
contiver um campo etag, mas nenhuma vinculação de papel, a política não concederá
papéis do IAM.
O campo etag contém um valor como BwUjMhCsNvY=. Ao atualizar, inclua o campo etag na política de permissão atualizada.
Se a política tiver sido modificada desde que
você a recuperou, etag não será correspondente, e haverá falha na atualização. Para a
API REST, você recebe o código de status HTTP 409 Conflict e o corpo da resposta
é semelhante ao seguinte:
{
"error": {
"code": 409,
"message": "There were concurrent policy changes. Please retry the whole read-modify-write with exponential backoff.",
"status": "ABORTED"
}
}
Se você receber esse erro, repita toda a série de operações: leia a política novamente, modifique-a conforme necessário e grave a política atualizada. Execute novas tentativas automaticamente, com espera exponencial, em qualquer ferramenta usada para gerenciar políticas de permissão.
Exemplo: política simples
Considere o seguinte exemplo de política de permissão que vincula um principal a um papel:
{
"bindings": [
{
"members":