Políticas de limite de acesso principal

Visualização

Esse recurso está sujeito aos "Termos de ofertas pré-GA" na seção "Termos de Serviço gerais" dos Termos específicos de serviço. Os recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

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 acessem recursos em outras organizações, o que pode ajudar a evitar ataques de phishing ou a exfiltração de dados.

Para saber mais sobre os outros tipos de políticas de controle de acesso que o Identity and Access Management (IAM) oferece, consulte Tipos de políticas.

Como funcionam as políticas de limite de acesso principal

Por padrão, os principais estão qualificados para acessar qualquer recurso do Google Cloud. Isso significa que, se um principal tiver uma permissão no recurso e não for negado, 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 pode acessar. Se uma política de limite de acesso de principal tornar um principal não qualificado para acessar um recurso, o acesso dele 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 de principal podem bloquear algumas, mas não todas, as permissões do Identity and Access Management (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 de 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 de 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 de 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 ao principal nesse recurso.

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

• O principal Tal ([e-mail]) 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 de principal que indique que os principais de altostrat.com só estão qualificados para acessar recursos em altostrat.com. Em seguida, é possível criar uma vinculação de política para anexar essa política a todos os principais na organização altostrat.com. Com essa política em vigor, Tal não poderá acessar 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ão qualificados para acessar, as políticas de limite de acesso de principal impedem que eles usem algumas, mas não todas, as permissões do Identity and Access Management (IAM) para acessar o recurso.

Se uma política de limite de acesso de principal bloquear uma permissão, o IAM aplica políticas de limite de acesso de principal para essa permissão. Em outras palavras, ela 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 a possibilidade de os principais usarem a permissão.

Por exemplo, imagine que um participante, Lee ([e-mail]), 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 de principal que o torna inelegível 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 de limite de acesso principal

Cada política de limite de acesso de 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 de principal pode bloquear. Você especifica a versão de aplicação ao criar ou atualizar uma política de limite de acesso de 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 de 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 suas 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 conferir 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 de principal.

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

Para vincular uma política de limite de acesso de principal a um conjunto de principais, crie uma vinculação de política que especifique a política de limite de acesso de principal que você quer aplicar e o conjunto de principais 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 de principal.

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

Para saber como gerenciar políticas de limite de acesso de principal, consulte Criar e aplicar políticas de limite de acesso de 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 principal
• 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 identidades de 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 da 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 encontrar o ID do seu espaço de trabalho, use um destes métodos: Use o comando gcloud organizations describe. O ID do seu espaço de trabalho está no campo directoryCustomerId da resposta. Use o método organizations.get na API Cloud Resource Manager. O ID do seu espaço de trabalho está no campo directoryCustomerId da resposta. Confira o ID do seu espaço de trabalho no Admin Console. Esse método exige a função de superadministrador do Google Workspace.	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 identidade 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 de 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 da 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 os principais em que a política é aplicável.

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 é aplicável.

É possível usar os atributos principal.type e principal.subject em condições para vinculações de políticas. Nenhum outro atributo é aceito em 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 para quais tipos de principais uma política de limite de acesso principal é aplicável.

  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 será aplicada apenas 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, [e-mail]. É possível usar condições com esse atributo para controlar exatamente quais principais estão sujeitos a uma política de limite de acesso de principal.

  Por exemplo, se você adicionar a expressão de condição a seguir a uma vinculação para uma política de limite de acesso principal, a política não será aplicada ao usuário [e-mail]:

  principal.subject != '[e-mail]'
  

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 [e-mail]. Essa conta de serviço está sujeita a uma política de limite de acesso do 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:

1. Você confirma que a única política de limite de acesso principal a que dev-project-service-account está sujeita é a que qualifica os principais para acessar todos os recursos em example.com.

2. Crie uma nova política de limite de acesso de principal que torne os principais qualificados para acessar recursos em dev-project e anexe-a ao conjunto de principais de 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 == '[e-mail]'"
   }
   

3. Você isenta dev-project-service-account da política de limite de acesso de 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 de principal ao conjunto principal da organização:

   "condition": {
     "title": "Exempt dev-project-service-account",
     "expression": "principal.subject != '[e-mail]' || principal.type != 'iam.googleapis.com/ServiceAccount'"
   }
   

   Para saber como atualizar as políticas de limite de acesso de principal, consulte Editar políticas de limite de acesso de principal.

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

Interações de políticas

O IAM avalia cada política de limite de acesso de principal em combinação com as políticas de permissão e negação e com outras políticas de limite de acesso de 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 de 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 sozinhas não dão aos principais acesso aos 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 de principal qualificar um principal para acessar um recurso, ele estará qualificado para acessar esse recurso, independentemente das outras políticas de limite de acesso de principal a que ele estiver sujeito. Como resultado, se um principal já estiver sujeito a uma política de limite de acesso de principal, não será possível adicionar políticas de limite de acesso de principal para reduzir o acesso de um principal.

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

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

Como resultado dessas políticas de limite de acesso de principal, Dana pode 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 de principal a que Dana está sujeito.

Por exemplo, é possível editar dev-staging-projects-policy para que ele não torne os principais 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 da 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.

Importante: se você remover uma política de limite de acesso de principal para reduzir o acesso de um principal, garanta que o principal esteja sempre sujeito a pelo menos uma política de limite de acesso de principal. Se um principal não estiver sujeito a nenhuma política de limite de acesso de principal, ele estará qualificado para acessar todos os recursos do Google Cloud. Para saber como reduzir o acesso de um principal com segurança, consulte Reduzir os recursos que os principais podem acessar.

No entanto, essas mudanças não afetam apenas Dana, mas também os outros principais sujeitos às políticas e vinculações de limite de acesso de principais modificadas. Se você quiser reduzir os recursos que um único principal pode acessar, use as vinculações de política condicionais.

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 de principais para recursos pai do Gerenciador de recursos, ou seja, pastas e organizações, sempre incluem todos os principais nos conjuntos de 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:

• 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 principais 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 principal 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 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 é 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 o limite de acesso principal impedir que principais não qualificados acessem um recurso visível publicamente depende se o recurso está armazenado em cache:

• Se o recurso estiver armazenado 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 de 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 podem acessar.

Por exemplo, a política de limite de acesso principal a seguir faz com que os principais que estão sujeitos à política sejam 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 de 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 de principal foi criada e PAB_POLICY_ID é o ID alfanumérico da política de limite de acesso de principal.
• uid: um ID exclusivo atribuído à política de limite de acesso de 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 de 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 de principal foi criada.
• updateTime: a hora em que a política de limite de acesso de principal foi atualizada pela última vez.

Detalhes

Cada política de limite de acesso de 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 de 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 Resource Manager (projetos, pastas e organizações) que você quer que os principais usuários tenham acesso. Qualquer principal que esteja sujeito a essa política pode acessar esses recursos.

    Cada política de limite de acesso de principal pode se referir a 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 em regras de limite de acesso principal é "ALLOW". Essa relação faz com que os principais sejam qualificados 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 de 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 de 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 de principal contém o nome de uma política, o nome do conjunto de principais a que a política está vinculada e metadados que descrevem a vinculação. Ela também pode conter condições que modificam os principais 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 que a política seja aplicada ao [e-mail] 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 [e-mail]",
    "expression": "principal.subject != '[e-mail]'"
  },
  "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 para políticas de limite de acesso de principal, esse valor é sempre PRINCIPAL_ACCESS_BOUNDARY.

• policy: a política de limite de acesso de principal a ser vinculada ao conjunto de principais de destino.

• policyUid: um ID exclusivo atribuído à política de limite de acesso de principal referenciada no campo policy.

• condition: opcional. Uma expressão lógica que afeta para quais principais o IAM aplica a 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 de acesso e condições de 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íticas 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 na 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 identidade da força de trabalho em example.com e todas as contas de serviço e pools de identidade da 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 estão qualificados para acessar todos os recursos.

Para que os principais não possam acessar recursos fora de example.com, crie uma política de limite de acesso de principal que os torne qualificados 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 os recursos em example.com. Eles não podem usar permissões bloqueadas pela política de limite de acesso de principal para acessar recursos fora do example.com, mesmo que tenham essas permissões nesses recursos.

Restringir as 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 só possam acessar recursos dentro dele.

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 de 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 de principal que qualifica todos os principais em example.com para acessar todos os recursos em example.com. As políticas de limite de acesso de 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 sejam 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. Eles não podem usar permissões que são bloqueadas pela política de limite de acesso principal para acessar recursos fora do example-dev, mesmo que tenham permissão para esses recursos.

A seguir

• Saiba como criar e aplicar políticas de limite de acesso de principal.
• Analise a permissão que cada versão de aplicação da política de limite de acesso de principal bloqueia.