Resolver problemas de políticas

Nesta página, descrevemos como solucionar problemas de políticas de permissão, negação e limite de acesso principal do Identity and Access Management (IAM).

Ver todas as políticas de permissão e negação que se aplicam a um recurso

No Trusted Cloud, as políticas de permissão e negação a seguir afetam o acesso a um recurso:

  • A política de permissão do recurso
  • As políticas de negação do recurso, se houver
  • As políticas de permissão do projeto pai, pasta e organização do recurso, se houver
  • As políticas de negação do projeto pai, da pasta e da organização do recurso, se houver

As políticas de permissão e negação de projetos, pastas e organizações pai afetam o acesso a um recurso devido à herança de política. Quando você anexa uma política de permissão ou negação a um projeto, pasta ou organização, essa política também se aplica a todos os recursos dentro do projeto, da pasta ou da organização.

Por exemplo, se uma política de negação para uma organização disser que um principal não pode usar uma permissão específica, o principal não poderá usar essa permissão para nenhum recurso dentro da organização. Essa regra se aplica mesmo que as pastas e os projetos nessa organização tenham políticas de negação mais permissivas ou permitam políticas que dão ao principal a permissão.

Da mesma forma, se uma política de permissão para um projeto conceder a um principal uma permissão específica, o principal terá essa permissão para qualquer recurso no projeto, desde que essa permissão não seja negada.

A união de todas essas políticas é chamada de política aplicável ou política vigente do recurso.

No Trusted Cloud, é possível conseguir uma lista de todas as políticas de permissão e negação que afetam o acesso a um projeto usando o comando gcloud beta projects get-ancestors-iam-policy com a flag --include-deny. Juntas, essas políticas compõem a política aplicável ao projeto. É possível investigar cada política para ver como isso afeta o acesso do principal.

gcloud

Antes de usar os dados do comando abaixo, faça estas substituições:

  • PROJECT_ID: o ID do projeto do Trusted Cloud . Os IDs do projeto são strings alfanuméricas, como my-project.

Execute o comando gcloud beta projects get-ancestors-iam-policy:

Linux, macOS ou Cloud Shell

gcloud beta projects get-ancestors-iam-policy PROJECT_ID --include-deny --format=json

Windows (PowerShell)

gcloud beta projects get-ancestors-iam-policy PROJECT_ID --include-deny --format=json

Windows (cmd.exe)

gcloud beta projects get-ancestors-iam-policy PROJECT_ID --include-deny --format=json

A resposta contém as políticas de permissão e negação do projeto; quaisquer pastas que sejam ancestrais do projeto; e a organização. O exemplo a seguir mostra as políticas de permissão da organização 1234567890123 e do projeto my-project, além de uma política de negação para o projeto my-project: 

[
  {
    "id": "1234567890123",
    "policy": {
      "bindings": [
        {
          "members": [
            "principalSet://iam.googleapis.com/locations/global/workforcePools/example-pool/group/cloud-admins"
          ],
          "role": "roles/iam.denyAdmin"
        },
        {
          "members": [
            "principal://iam.googleapis.com/locations/global/workforcePools/example-pool/subject/raha@example.com"
          ],
          "role": "roles/iam.serviceAccountAdmin"
        }
      ],
      "etag": "BwXW6Eab7TI=",
      "version": 1
    },
    "type": "organization"
  },
  {
    "id": "my-project",
    "policy": {
      "bindings": [
        {
          "members": [
            "principalSet://iam.googleapis.com/locations/global/workforcePools/example-pool/group/cloud-admins"
          ],
          "role": "roles/owner"
        }
      ],
      "etag": "BwXXjOM7L6M=",
      "type": "project"
    }
  },
  {
    "id": "my-project",
    "policy": {
      "createTime": "2022-02-14T21:46:35.865279Z",
      "displayName": "My deny policy",
      "etag": "MTgyMzg2ODcwNTEyMjMxMTM3Mjg=",
      "kind": "DenyPolicy",
      "name": "policies/cloudresourcemanager.googleapis.com%2Fprojects%2F123456789012/denypolicies/my-deny-policy",
      "rules": [
        {
          "denyRule": {
            "deniedPermissions": [
              "iam.googleapis.com/serviceAccounts.create"
            ],
            "deniedPrincipals": [
              "principal://iam.googleapis.com/locations/global/workforcePools/example-pool/subject/raha@example.com"
            ]
          },
          "description": "Prevent service account creation"
        }
      ],
      "uid": "c83e3dc3-d8a6-6f51-4018-814e9f200b05",
      "updateTime": "2022-02-14T21:46:35.865279Z"
    },
    "type": "project"
  }
]

Neste exemplo, Raha recebe o papel de administrador da conta de serviço (roles/iam.serviceAccountAdmin) na organização, mas o projeto tem uma política de negação que impede Raha de usar a permissão iam.googleapis.com/serviceAccounts.create. Como resultado, se o Raha tentar criar uma conta de serviço no projeto my-project, a solicitação será negada.

Em alguns casos, talvez seja necessário visualizar apenas a política de permissão efetiva de um recurso, por exemplo, se sua organização não usar políticas de negação. Nesses casos, é possível usar os seguintes métodos para ver a política de permissão efetiva:

  • Veja a política de permissão do IAM do recurso no console doTrusted Cloud . O console Trusted Cloud mostra automaticamente a política vigente de cada recurso.

    Para saber como ver a política de permissão do IAM de um recurso no console doTrusted Cloud , consulte Ver o acesso atual.

  • Use a API Cloud Asset para acessar a política de permissão efetiva do recurso. Para saber mais, consulte Como ver políticas do IAM eficazes.