Políticas de limite de acesso principal

As políticas de limite de acesso principal (PAB) permitem restringir os recursos que os principais podem acessar.

Por exemplo, é possível usar políticas de limite de acesso principal para impedir que os principais usuários acessem recursos em outras organizações, o que pode ajudar a evitar ataques de phishing ou exfiltração de dados.

Para saber mais sobre os outros tipos de políticas de controle de acesso que o gerenciamento de identidade e acesso (IAM) oferece, consulte Tipos de políticas.

Como funcionam as políticas de limite de acesso principal

Por padrão, as identidades principais podem acessar qualquer recurso do Google Cloud. Isso significa que, se um diretor tiver uma permissão no recurso e não tiver essa permissão negada, ele poderá usar essa permissão para acessar o recurso.

Com as políticas de limite de acesso principal, é possível restringir os recursos que um principal está qualificado para acessar. Se uma política de limite de acesso principal tornar um principal inelegível para acessar um recurso, o acesso a esse recurso será limitado, independentemente dos papéis concedidos.

Quando os principais tentam acessar recursos que não estão qualificados para acesso, as políticas de limite de acesso principal podem bloquear algumas, mas não todas, as permissões de gerenciamento de identidade e acesso (IAM). Para saber mais sobre quais permissões são bloqueadas, consulte Permissões que o limite de acesso principal pode bloquear.

As políticas de limite de acesso principal são compostas por regras de limite de acesso principal. Cada regra de limite de acesso principal define um conjunto de recursos que os principais afetados podem acessar. É possível criar até 1.000 políticas de limite de acesso principal na sua organização.

Depois de criar uma política de limite de acesso principal, crie uma vinculação de política para aplicar a política a um conjunto de principais.

Um principal pode estar sujeito a uma ou mais políticas de limite de acesso principal. Cada principal só pode acessar os recursos listados nessas políticas. Para todos os outros recursos, o acesso do principal a esse recurso é limitado, mesmo que você conceda funções a ele.

Como as políticas de limite de acesso principal são associadas a principais e não a recursos, é possível usá-las para impedir que os principais acessem recursos que não são seus. Por exemplo, considere o seguinte cenário:

Política de limite de acesso principal que impede o acesso a um recurso

O principal Tal (tal@altostrat.com) faz parte da organização do Google Workspace altostrat.com.
Tal recebe o papel de administrador do Storage (roles/storage.admin) em um bucket do Cloud Storage em uma organização diferente, cymbalgroup.com. Esse papel contém a permissão storage.objects.get, que é necessária para visualizar objetos no bucket.
Não há políticas de negação em cymbalgroup.com que impeçam Tal de usar a permissão storage.objects.get.

Com políticas de permissão e negação, altostrat.com não pode impedir que Tal acesse objetos neste bucket externo. Nenhum principal altostrat.com tem permissão para editar a política de permissão do bucket. Portanto, eles não podem revogar o papel de Tal. Ela também não tem permissão para criar políticas de negação em cymbalgroup.com, então não pode usar uma política de negação para impedir que Tal acesse o bucket.

No entanto, com as políticas de limite de acesso principal, os administradores da altostrat.com podem garantir que Tal não possa acessar objetos no bucket cymbalgroup.com ou em qualquer bucket fora da altostrat.com. Para fazer isso, os administradores podem criar uma Política de limite de acesso principal que indique que as principais altostrat.com só estão qualificadas para acessar recursos em altostrat.com. Em seguida, eles podem criar uma vinculação de política para anexar essa política a todos os participantes da organização altostrat.com. Com essa política em vigor, Tal não poderá acessar os objetos no bucket cymbalgroup.com, mesmo que tenha recebido o papel de administrador do Storage no bucket.

Avaliação de fail open

Durante a versão de pré-lançamento da política de limite de acesso principal, as políticas de limite de acesso principal falham abertamente. Isso significa que, se o IAM não puder avaliar uma política de limite de acesso de principal, ele vai ignorar a política de limite de acesso de principal e avaliar as políticas de permissão e negação relevantes.

Permissões bloqueadas pelas políticas de limite de acesso principal

Quando os principais tentam acessar um recurso que não está disponível para eles, as políticas de limite de acesso principal impedem que eles usem algumas, mas não todas, as permissões de gerenciamento de identidade e acesso (IAM) para acessar o recurso.

Se uma política de limite de acesso principal bloquear uma permissão, o IAM aplica as políticas de limite de acesso principal para essa permissão. Em outras palavras, ele impede que os principais que não estão qualificados para acessar um recurso usem essa permissão.

Se uma política de limite de acesso principal não bloquear uma permissão, ela não terá efeito sobre se os principais podem usar a permissão.

Por exemplo, imagine que um participante, Lee (lee@example.com), recebe o papel de desenvolvedor do Dataflow (roles/dataflow.developer). Esse papel inclui a permissão dataflow.jobs.snapshot, que permite que Lee faça snapshots de jobs do Dataflow. Lee também está sujeito a uma política de limite de acesso principal que o torna não qualificado para acessar recursos fora de example.com. No entanto, se as políticas de limite de acesso principal não bloquearem a permissão dataflow.jobs.snapshot, Lee ainda poderá fazer snapshots de jobs do Dataflow em organizações fora de example.com.

As permissões que uma política de limite de acesso principal bloqueia dependem da versão de aplicação do limite de acesso principal.

Versões de aplicação do limite de acesso principal

Cada política de limite de acesso principal especifica uma versão de aplicação, que identifica uma lista predefinida de permissões do IAM que a política de limite de acesso principal pode bloquear. Você especifica a versão de aplicação ao criar ou atualizar uma política de limite de acesso principal. Se você não especificar uma versão de aplicação, o IAM vai usar a versão de aplicação mais recente e continuar usando essa versão até que você a atualize.

Periodicamente, o IAM adiciona novas versões de aplicação de limite de acesso principal que podem bloquear outras permissões. Cada nova versão também pode bloquear todas as permissões da versão anterior.

Para bloquear as permissões em uma nova versão de aplicação, atualize as políticas de limite de acesso principal para usar a nova versão. Se você quiser que a versão de aplicação seja atualizada automaticamente conforme novas versões forem lançadas, use o valor latest ao criar a política. No entanto, não recomendamos o uso desse valor, porque ele pode fazer com que os administradores percam o acesso aos recursos inesperadamente.

Para uma lista completa das permissões bloqueadas por cada versão de aplicação, consulte Permissões bloqueadas pelas políticas de limite de acesso principal.

Vincular políticas de limite de acesso principal a conjuntos de principais

Para vincular uma política de limite de acesso principal a um conjunto principal, crie uma vinculação de política que especifique a política de limite de acesso principal que você quer aplicar e o conjunto principal em que ela será aplicada. Depois de vincular a política a um conjunto de principais, os principais nesse conjunto só podem acessar os recursos incluídos nas regras da política de limite de acesso principal.

É possível vincular uma política de limite de acesso principal a qualquer número de conjuntos de principais. Cada conjunto principal pode ter até 10 políticas de limite de acesso principal vinculadas a ele.

Para saber como gerenciar políticas de limite de acesso principal, consulte Criar e aplicar políticas de limite de acesso principal.

Conjuntos principais com suporte

A tabela a seguir lista os tipos de conjuntos principais que podem ser vinculados a políticas de limite de acesso principal. Cada linha contém o seguinte:

O tipo de conjunto principal
Os principais nesse tipo de conjunto
O formato dos IDs para esse tipo de conjunto de principais
O recurso do Resource Manager (projeto, pasta ou organização) que é pai das vinculações de políticas para esse tipo de principal definido

Conjunto principal	Detalhes	Recurso pai das vinculações de políticas
Pool de identidade da força de trabalho	Contém todas as identidades no pool de identidade da força de trabalho especificado. Formato: `//iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID`	A organização que contém o pool de identidade da força de trabalho
Pool de identidade da carga de trabalho	Contém todas as identidades no pool de Identidade de carga de trabalho especificado. Formato: `//iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/WORKLOAD_POOL_ID`	O projeto que contém o pool de identidade da carga de trabalho
Domínio do Google Workspace	Contém todas as identidades no domínio do Google Workspace especificado. Formato: `//iam.googleapis.com/locations/global/workspace/WORKSPACE_ID` Para saber como encontrar o ID do seu espaço de trabalho, consulte Encontrar seu ID de cliente.	A organização associada ao domínio do Google Workspace
Conjunto principal do projeto	Contém todas as contas de serviço e pools de identidades de carga de trabalho no projeto especificado. Formato: `//cloudresourcemanager.googleapis.com/projects/PROJECT_ID`	O projeto
Conjunto principal da pasta	Contém todas as contas de serviço e todos os pools de Identidades de carga de trabalho em qualquer projeto na pasta especificada. Formato: `//cloudresourcemanager.googleapis.com/folders/FOLDER_ID`	A pasta
Conjunto principal da organização	Contém as seguintes identidades: Todas as identidades em todos os domínios associados ao seu ID de cliente do Google Workspace Todos os pools de identidade da força de trabalho na sua organização Todas as contas de serviço e pools de identidade de carga de trabalho em qualquer projeto na organização Formato: `//cloudresourcemanager.googleapis.com/organizations/ORGANIZATION_ID`	A organização

Vinculações de políticas condicionais para políticas de limite de acesso principal

É possível usar expressões de condição em vinculações de políticas para políticas de limite de acesso principal para refinar ainda mais quais principais a política se aplica.

As expressões condicionais para vinculações de políticas consistem em uma ou mais instruções unidas por até 10 operadores lógicos (&&, || ou !). Cada instrução expressa uma regra de controle baseada em atributo que se aplica à vinculação de políticas e, por fim, determina se a política se aplica.

É possível usar os atributos principal.type e principal.subject em condições para vinculações de políticas. Nenhum outro atributo é aceito nas condições para vinculações de políticas.

O atributo principal.type indica o tipo de participante na solicitação, por exemplo, contas de serviço ou identidades em um pool de identidades da carga de trabalho. É possível usar condições com esse atributo para controlar a quais tipos de principais uma política de limite de acesso principal se aplica.

Por exemplo, se você adicionar a seguinte expressão de condição a uma vinculação para uma política de limite de acesso principal, a política só será aplicada a contas de serviço:
```
principal.type == 'iam.googleapis.com/ServiceAccount'
```
O atributo principal.subject indica a identidade do principal na solicitação, por exemplo, cruz@example.com. É possível usar condições com esse atributo para controlar exatamente quais principais estão sujeitos a uma política de limite de acesso principal.

Por exemplo, se você adicionar a seguinte expressão de condição a uma vinculação para uma política de limite de acesso principal, ela não será aplicada ao usuário special-admin@example.com:
```
principal.subject != 'special-admin@example.com'
```

Para saber mais sobre os valores que podem ser usados para essas condições, consulte a referência do atributo de condições.

Exemplo: usar condições para reduzir os recursos que um principal pode acessar

Uma das maneiras de usar condições em vinculações de políticas de limite de acesso principal é reduzir os recursos que um único principal pode acessar.

Imagine que você tenha uma conta de serviço, dev-project-service-account, com o endereço de e-mail dev-project-service-account@dev-project.iam.gserviceaccount.com. Essa conta de serviço está sujeita a uma política de limite de acesso principal que torna os principais qualificados para acessar todos os recursos na organização example.com. Essa política está anexada ao conjunto principal da organização example.com.

Você decide que não quer que dev-project-service-account tenha permissão para acessar todos os recursos em example.com. Você só quer que ele tenha permissão para acessar recursos em dev-project. No entanto, você não quer mudar os recursos que outros principais no conjunto de principais example.com estão qualificados para acessar.

Para fazer essa mudança, siga o procedimento para reduzir os recursos que os principais podem acessar, mas adicione uma condição à vinculação de políticas em vez de excluí-la:

Você confirma que a única política de limite de acesso principal a que dev-project-service-account está sujeita é a que torna os principais qualificados para acessar todos os recursos em example.com.
Você cria uma nova política de limite de acesso principal que qualifica os principais para acessar recursos em dev-project e a anexa ao principal definido para dev-project. Use a seguinte condição na vinculação de políticas para garantir que a política seja aplicada apenas para dev-project-service-account:
```
"condition": {
  "title": "Only dev-project-service-account",
  "expression": "principal.type == 'iam.googleapis.com/ServiceAccount' && principal.subject == 'dev-project-service-account@dev-project.iam.gserviceaccount.com'"
}
```
Você isenta dev-project-service-account da política de limite de acesso principal que torna os principais qualificados para acessar todos os recursos em example.com. Para fazer isso, adicione a seguinte condição à vinculação de políticas que anexa essa política de limite de acesso principal ao conjunto de principais da organização:
```
"condition": {
  "title": "Exempt dev-project-service-account",
  "expression": "principal.subject != 'dev-project-service-account@dev-project.iam.gserviceaccount.com' || principal.type != 'iam.googleapis.com/ServiceAccount'"
}
```
Para saber como atualizar as políticas de limite de acesso principal, consulte Editar políticas de limite de acesso principal.

Depois de adicionar essa condição à vinculação de políticas, dev-project-service-account não estará mais qualificado para acessar todos os recursos em example.com. Em vez disso, ele só poderá acessar recursos em dev-project.

Interações de políticas

O IAM avalia cada política de limite de acesso principal em combinação com as políticas de permissão e negação e com outras políticas de limite de acesso principal. Todas essas políticas são usadas para determinar se um principal pode acessar um recurso.

Interação com outros tipos de políticas

Quando um principal tenta acessar um recurso, o IAM avalia todas as políticas de permissão e negação relevantes de acesso principal para ver se o principal tem permissão para acessar o recurso. Se alguma dessas políticas indicar que o principal não pode acessar o recurso, o IAM vai impedir o acesso.

Como resultado, se uma política de limite de acesso principal impedir que um principal acesso um recurso, o IAM impedirá que ele acesse esse recurso, independentemente das políticas de permissão e negação anexadas ao recurso.

Além disso, as políticas de limite de acesso principal por si só não dão acesso a recursos. Embora as políticas de limite de acesso principal possam tornar um principal qualificado para acessar um recurso, apenas as políticas de permissão podem conceder o acesso ao principal.

Para saber mais sobre a avaliação de políticas do IAM, consulte Avaliação de políticas.

Interação entre políticas de limite de acesso principal

Se qualquer política de limite de acesso principal qualificar um principal para acessar um recurso, ele poderá acessar esse recurso, independentemente das outras políticas de limite de acesso principal a que o principal está sujeito. Como resultado, se um principal já estiver sujeito a uma política de limite de acesso principal, não será possível adicionar políticas de limite de acesso principal para reduzir o acesso de um principal.

Por exemplo, imagine que um principal, Dana (dana@example.com), esteja sujeito a uma única política de limite de acesso principal, prod-projects-policy. Essa política faz com que os participantes possam acessar recursos em prod-project. Dana está sujeita a essa política porque ela está vinculada ao conjunto de principais da organização.

Você cria uma nova política de limite de acesso principal, dev-staging-projects-policy, que qualifica os principais para acessar recursos em dev-project e staging-project e, em seguida, vincula ao conjunto principal da organização.

Como resultado dessas políticas de limite de acesso principal, Dana tem direito de acessar recursos em dev-project, staging-project e prod-project.

Se você quiser reduzir os recursos que Dana pode acessar, modifique ou remova as políticas de limite de acesso principal a que ela está sujeita.

Por exemplo, é possível editar dev-staging-projects-policy para que ele não torne os principais participantes qualificados para acessar recursos em dev-project. Assim, Dana só poderá acessar recursos em staging-project e prod-project.

Também é possível remover prod-projects-policy excluindo a vinculação de política que a vincula ao conjunto principal da organização. Nesse caso, Dana só poderá acessar os recursos em dev-project e staging-project.

No entanto, essas mudanças não afetam apenas Dana, mas também os outros participantes que estão sujeitos às políticas e vinculações de limite de acesso do participante modificado. Se você quiser reduzir os recursos que um único principal tem direito de acessar, use as vinculações de política condicional.

Herança de políticas

As políticas de limite de acesso principal são anexadas a conjuntos de principais, não a recursos do Gerenciador de recursos. Como resultado, elas não são herdadas pela hierarquia de recursos da mesma forma que as políticas de permissão e negação.

No entanto, os conjuntos principais de recursos principais do Resource Manager, ou seja, pastas e organizações, sempre incluem todos os principais nos conjuntos principais dos descendentes. Por exemplo, se um principal for incluído no conjunto principal de um projeto, ele também será incluído nos conjuntos principais de qualquer pasta ou organização pai.

Por exemplo, considere uma organização, example.com. Essa organização está associada ao domínio example.com e tem os seguintes recursos do Gerenciador de recursos:

Hierarquia de recursos para example.com

Uma organização, example.com
Um projeto, project-1, que é filho da organização
Uma pasta, folder-a, que é filha da organização
Dois projetos, project-2 e project-3, que são filhos de folder-a

Os conjuntos principais desses recursos contêm as seguintes identidades:

Conjunto principal	Identidades do Google Workspace no domínio `example.com`	Pools de federação de identidade da força de trabalho em `example.com`	Contas de serviço e pools de identidade da carga de trabalho em `project-1`	Contas de serviço e pools de identidade da carga de trabalho em `project-2`	Contas de serviço e pools de identidade da carga de trabalho em `project-3`
Conjunto principal para `example.com`
Conjunto principal para `folder-a`
Conjunto principal para `project-1`
Conjunto principal para `project-2`
Conjunto principal para `project-3`

Como resultado, os seguintes princípios são afetados pelas seguintes políticas de limite de acesso principal:

Uma identidade do Google Workspace no domínio example.com está no conjunto de principais de example.com e será afetada pelas políticas de limite de acesso de principais vinculadas a esse conjunto.
Uma conta de serviço em project-1 está nos conjuntos de principais de project-1 e example.com e será afetada pelas políticas de limite de acesso principal vinculadas a qualquer um desses conjuntos.
Uma conta de serviço em project-3 está nos conjuntos de principais de project-3, folder-a e example.com e será afetada pelas políticas de limite de acesso de principal vinculadas a qualquer um desses conjuntos.

Políticas de limite de acesso principal e recursos em cache

Alguns serviços do Google Cloud armazenam em cache recursos visíveis publicamente. Por exemplo, o Cloud Storage armazena em cache objetos que são legíveis publicamente.

A possibilidade de que o limite de acesso principal impeça que diretores não qualificados acessem um recurso visível publicamente depende se o recurso está armazenado em cache:

Se o recurso estiver em cache, o limite de acesso do principal não poderá impedir que os principais acessem o recurso.
Se o recurso não estiver armazenado em cache, o limite de acesso principal vai impedir que os principais não qualificados acessem o recurso.

Em todos os casos, as políticas de limite de acesso principal impedem que participantes não qualificados modifiquem ou excluam recursos visíveis publicamente.

Estrutura de uma política de limite de acesso principal

Uma política de limite de acesso principal é um conjunto de metadados e detalhes da política de limite de acesso principal. Os metadados fornecem informações como o nome da política e quando ela foi criada. Os detalhes da política definem o que ela faz, por exemplo, os recursos que os principais afetados estão qualificados para acessar.

Por exemplo, a política de limite de acesso principal a seguir faz com que os principais sujeitos a ela fiquem qualificados para acessar os recursos na organização com o ID 0123456789012.

{
  "name": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-policy",
  "uid": "puid_0123456789012345678",
  "etag": "W/\"Gh/PcTdJD/AWHUhPW45kdw==\"",
  "displayName": "Example policy",
  "annotations": {
    "example-key": "example-value"
  },
  "createTime": "2024-01-02T15:01:23Z",
  "updateTime": "2024-01-02T15:01:23Z",
  "details": {
    "rules": [
      {
        "description": "Example principal access boundary policy rule",
        "resources": [
          "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
        ],
        "effect": "ALLOW"
      }
    ],
    "enforcementVersion": "1"
  }
}

As seções a seguir descrevem os metadados e detalhes de uma política de limite de acesso principal.

Metadados

As políticas de limite de acesso principal contêm os seguintes metadados:

name: o nome da política de limite de acesso principal. Esse nome tem o formato organizations/ORGANIZATION_ID/locations/global/principalAccessBoundaryPolicies/PAB_POLICY_ID, em que ORGANIZATION_ID é o ID numérico da organização em que a política de limite de acesso principal foi criada e PAB_POLICY_ID é o ID alfanumérico da política de limite de acesso principal.
uid: um ID exclusivo atribuído à política de limite de acesso principal.
etag: um identificador do estado atual da política. Esse valor muda quando você atualiza a política. Para evitar atualizações conflitantes, o valor etag precisa corresponder ao valor armazenado no IAM. Se os valores de etag não corresponderem, a solicitação falhará.
displayName: um nome legível por humanos para a política de limite de acesso principal.
annotations: opcional. Uma lista de pares de chave-valor definidos pelo usuário. É possível usar essas anotações para adicionar metadados extras à política, por exemplo, quem criou a política ou se ela foi implantada por um pipeline automatizado. Para mais informações sobre anotações, consulte Anotações.
createTime: o horário em que a política de limite de acesso principal foi criada.
updateTime: o horário em que a política de limite de acesso principal foi atualizada pela última vez.

Detalhes

Cada política de limite de acesso principal contém um campo details. Esse campo contém as regras de limite de acesso principal e a versão de aplicação:

rules: uma lista de regras de limite de acesso principal, que definem os recursos que os principais afetados podem acessar. Cada regra contém os seguintes campos:
- description: uma descrição legível por humanos da regra.
- resources: uma lista de recursos do Gerenciador de recursos (projetos, pastas e organizações) que você quer que os principais tenham acesso. Qualquer principal sujeito a essa política está qualificado para acessar esses recursos.
  
  Cada política de limite de acesso principal pode referenciar no máximo 500 recursos em todas as regras da política.
- effect: a relação que os principais têm com os recursos listados no campo resources. O único efeito que pode ser especificado nas regras de limite de acesso principal é "ALLOW". Essa relação faz com que as principais estejam qualificadas para acessar os recursos listados na regra.
enforcementVersion: a versão de aplicação que o IAM usa ao aplicar a política. A versão da política de limite de acesso principal determina quais permissões ela pode bloquear.

Para mais informações sobre as versões da política de limite de acesso principal, consulte Versões de aplicação do limite de acesso principal nesta página.

Estrutura de uma vinculação de política

Uma vinculação de política para uma política de limite de acesso principal contém o nome de uma política, o nome do principal definido para vincular a política e metadados que descrevem a vinculação de política. Ela também pode conter condições que modificam os princípios exatos a que a política se aplica.

Por exemplo, a vinculação de políticas a seguir vincula a política example-policy a todos os principais participantes da organização example.com, que tem o ID 0123456789012. A vinculação de políticas também contém uma condição que impede a aplicação da política para o super-admin@example.com principal.

{
  "name": "organizations/0123456789012/locations/global/policyBindings/example-policy-binding",
  "uid": "buid_01234567890123456789", 
  "etag": "W/\"cRMdDXbT82aLuZlvoL9Gqg==\"",
  "displayName": "Example policy binding",
  "annotations": {
    "example-key": "example-value"
  },
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
  },
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-policy",
  "policyUid": "puid_0123456789012345678",
  "condition": {
    "title": "Exempt principal",
    "description": "Don't enforce the policy for super-admin@example.com",
    "expression": "principal.subject != 'super-admin@example.com'"
  },
  "createTime": "2024-01-02T17:00:16Z",
  "updateTime": "2024-01-02T17:00:16Z"
}

Cada vinculação de política contém os seguintes campos:

name: o nome da vinculação de política. Esse nome tem o formato RESOURCE_TYPE/RESOURCE_ID/locations/global/policyBindings/BINDING_ID, em que RESOURCE_TYPE/RESOURCE_ID é o tipo e o ID do recurso pai da vinculação de políticas e BINDING_ID é o ID alfanumérico da vinculação de políticas.
uid: um ID exclusivo atribuído à vinculação de políticas.
etag: um identificador do estado atual da política. Esse valor muda quando você atualiza a política. Para evitar atualizações conflitantes, o valor etag precisa corresponder ao valor armazenado no IAM. Se os valores de etag não corresponderem, a solicitação falhará.
displayName: um nome legível para a vinculação de políticas.
annotations: opcional. Uma lista de pares de chave-valor definidos pelo usuário. É possível usar essas anotações para adicionar metadados extras à vinculação de políticas, por exemplo, quem criou a vinculação de políticas ou se ela foi implantada por um pipeline automatizado. Para mais informações sobre anotações, consulte Anotações.
target: o principal definido para vincular a política. O valor tem o formato {"principalSet": PRINCIPAL_SET}, em que PRINCIPAL_SET é o ID do conjunto principal ao qual você quer vincular a política.

Cada destino pode ter até 10 políticas vinculadas a ele.
policyKind: o tipo de política que a vinculação de políticas referencia. Para vinculações de políticas de limite de acesso principal, esse valor é sempre PRINCIPAL_ACCESS_BOUNDARY.
policy: a política de limite de acesso principal a ser vinculada ao conjunto de membros principal de destino.
policyUid: um ID exclusivo atribuído à política de limite de acesso principal referenciada no campo policy.
condition: opcional. Uma expressão lógica que afeta os principais princípios que o IAM aplica à política. Se a condição for avaliada como verdadeira ou não puder ser avaliada, o Identity and Access Management vai aplicar a política ao principal que está fazendo a solicitação. Se a condição for avaliada como falsa, o Identity and Access Management não vai aplicar a política para o principal. Para mais informações, consulte Limite e condições de acesso principal nesta página.
createTime: o horário em que a vinculação de política foi criada.
updateTime: o horário em que a vinculação de políticas foi atualizada pela última vez.

Casos de uso

Confira a seguir situações comuns em que convém usar políticas de limite de acesso principal e exemplos de políticas de limite de acesso principal e vinculações de política que podem ser criadas em cada caso. Para saber como criar políticas de limite de acesso principal e vinculá-las a conjuntos de principais, consulte Criar e aplicar políticas de limite de acesso principal.

Restringir os principais a recursos na sua organização

É possível usar políticas de limite de acesso principal para garantir que os principais da sua organização só possam acessar recursos dentro dela.

Por exemplo, imagine que você quer garantir que todos os principais na organização example.com só possam acessar recursos em example.com. Os participantes em example.com incluem todas as identidades no domínio example.com, todos os pools de identidades de força de trabalho em example.com e todas as contas de serviço e pools de identidades de carga de trabalho em qualquer projeto em example.com.

Você não tem políticas de limite de acesso principal que se aplicam a nenhum dos principais na sua organização. Como resultado, todos os principais são qualificados para acessar todos os recursos.

Para que os principais não tenham qualificação para acessar recursos fora de example.com, crie uma Política de limite de acesso principal que os qualifique para acessar recursos em example.com:

{
  "name": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-org-only",
  "displayName": "Boundary for principals in example.org",
  "details": {
    "rules": [
      {
        "description": "Principals are only eligible to access resources in example.org",
        "resources": [
            "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
        ],
        "effect": "ALLOW"
      }
    ],
    "enforcementVersion": "1"
  }
}

Em seguida, crie uma vinculação de política para vincular essa política ao conjunto de principais:

{
  "name": "organizations/0123456789012/locations/global/policyBindings/example-org-only-binding",
  "displayName": "Bind policy to all principals in example.com",
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
  },
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-org-only"
}

Agora, todos os participantes em example.com somente estão qualificados para acessar recursos em example.com. Não é possível usar permissões que são bloqueadas pela política de limite de acesso principal para acessar recursos fora do example.com, mesmo que o usuário tenha essas permissões nesses recursos.

Restringir contas de serviço a recursos em um único projeto

É possível usar políticas de limite de acesso principal para garantir que as contas de serviço em um projeto específico estejam qualificadas para acessar apenas os recursos desse projeto.

Por exemplo, imagine que você tem um projeto, example-dev. Você quer garantir que as contas de serviço em example-dev só estejam qualificadas para acessar recursos em example-dev.

Você tem uma política de limite de acesso principal que torna todos os principais da sua organização, incluindo as contas de serviço em example-dev, qualificados para acessar recursos em example.com. Para saber como é esse tipo de política, consulte Restringir principais a recursos na sua organização.

Para que as contas de serviço em example-dev não tenham qualificação para acessar recursos fora de example-dev, primeiro crie uma política de limite de acesso principal que qualifique os principais para acessar recursos em example-dev.

{
  "name": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-dev-only",
  "displayName": "Boundary for principals in example-dev",
  "details": {
    "rules": [
      {
        "description": "Principals are only eligible to access resources in example-dev",
        "resources": [
          "//cloudresourcemanager.googleapis.com/projects/example-dev"
        ],
        "effect": "ALLOW"
      }
    ],
    "enforcementVersion": "1"
  }
}

Em seguida, crie uma vinculação de política para vincular essa política a todos os principais em example-dev e adicione uma condição para que a vinculação de política seja aplicada apenas a contas de serviço:

{
  "name": "organizations/0123456789012/locations/global/policyBindings/example-dev-only-binding",
  "displayName": "Bind policy to all service accounts in example-dev",
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/projects/example-dev"
  },
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-dev-only",
  "condition": {
    "title": "Only service accounts",
    "description": "Only enforce the policy if the principal in the request is a service account",
    "expression": "principal.type == 'iam.googleapis.com/ServiceAccount'"
  }
}

No entanto, essa política por si só não restringe a qualificação das contas de serviço. Isso ocorre porque há uma política de limite de acesso principal que faz com que todos os principais em example.com estejam qualificados para acessar todos os recursos em example.com. As políticas de limite de acesso principal são aditivas, então as contas de serviço em example-dev ainda estão qualificadas para acessar todos os recursos em example.com.

Para garantir que as contas de serviço em example-dev estejam apenas qualificadas para acessar recursos em example-dev, adicione uma condição à vinculação de política da política de limite de acesso principal que impeça a aplicação para as contas de serviço em example-dev:

{
  "name": "organizations/0123456789012/locations/global/policyBindings/example-org-only-binding",
  "displayName": "Bind policy to all principals in example.com",
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
  },
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-org-only",
  "condition": {
    "title": "Exempt example-dev service accounts",
    "description": "Don't enforce the policy for service accounts in the example-dev project",
    "expression": "principal.type != 'iam.googleapis.com/ServiceAccount' || !principal.subject.endsWith('@example-dev.iam.gserviceaccount.com')"
  }
}

Agora, as contas de serviço em example-dev só podem acessar recursos em example-dev. Não é possível usar permissões bloqueadas pela política de limite de acesso principal para acessar recursos fora do example-dev, mesmo que o usuário tenha permissão para esses recursos.