Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
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).
Usar o solucionador de problemas de políticas
Se você precisar solucionar problemas de acesso de um principal específico, use o solucionador de problemas de políticas do IAM.
O solucionador de problemas de políticas ajuda a entender se uma conta principal
pode acessar um recurso. Com um principal, um recurso e uma permissão,
o solucionador de problemas de políticas examina as políticas de permissão, negação
e limite de acesso do principal, na sigla em inglês (PAB) que afetam o acesso do principal.
Em seguida, ele informa se, com base nessas políticas, o principal pode usar
a permissão especificada para acessar o recurso. Ele também lista as políticas
relevantes e explica como elas afetam o acesso do principal.
Para saber como usar o solucionador de problemas de políticas para resolver problemas de políticas de permissão, negação e limite de acesso do principal, consulte Resolver problemas de permissões do IAM.
Ver todas as políticas de permissão e negação que se aplicam a um recurso
No Google 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 Google 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 Google Cloud . Os IDs do projeto são strings alfanuméricas, como my-project.
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:
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 doGoogle Cloud . O console Google 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 doGoogle 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.
Pesquisar políticas de permissão
Se você precisar localizar uma vinculação de papel específica em uma política de permissão, pesquise a política de permissão.
O Inventário de recursos do Cloud permite pesquisar políticas de permissão para vinculações de papéis
que correspondam aos parâmetros especificados. É possível usar vários parâmetros de pesquisa,
incluindo:
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-08-21 UTC."],[[["\u003cp\u003ePolicy Troubleshooter for IAM helps determine if a principal can access a resource by examining allow policies, deny policies, and principal access boundary (PAB) policies, and it provides details on the relevant policies.\u003c/p\u003e\n"],["\u003cp\u003eAllow and deny policies at the resource, project, folder, and organization levels can affect access to a resource due to policy inheritance, where policies applied to parent entities are inherited by resources within them.\u003c/p\u003e\n"],["\u003cp\u003eThe \u003ccode\u003egcloud beta projects get-ancestors-iam-policy\u003c/code\u003e command with the \u003ccode\u003e--include-deny\u003c/code\u003e flag can be used to list all allow and deny policies that affect access to a project, collectively forming the effective policy.\u003c/p\u003e\n"],["\u003cp\u003eEven if a principal is granted a permission via an allow policy, a deny policy can override it, preventing the principal from using that permission on specific resources, as illustrated with the example of Raha and service account creation.\u003c/p\u003e\n"],["\u003cp\u003eCloud asset inventory can be used to locate specific roles bindings through a search feature that uses parameters such as the resource type, principal type, role, project, folder, and organization.\u003c/p\u003e\n"]]],[],null,["# Troubleshoot policies\n\nThis page describes how to troubleshoot\nIdentity and Access Management (IAM) allow, deny, and principal access boundary policies.\n\nUse Policy Troubleshooter\n-------------------------\n\nIf you need to troubleshoot access for a specific principal, use\nPolicy Troubleshooter for IAM.\nPolicy Troubleshooter helps you understand whether a principal can access a resource. Given a principal, a resource, and a permission, Policy Troubleshooter examines the allow policies, deny policies, and principal access boundary (PAB) policies that impact the principal's access. Then, it tells you whether, based on those policies, the principal can use the specified permission to access the resource. It also lists the relevant policies and explains how they affect the principal's access.\n\nTo learn how to use Policy Troubleshooter to troubleshoot allow\npolicies, deny policies, and principal access boundary policies, see [Troubleshoot\nIAM permissions](/policy-intelligence/docs/troubleshoot-access).\n\nView all allow and deny policies that apply to a resource\n---------------------------------------------------------\n\n\nIn Google Cloud, the following allow and deny policies affect access\nto a resource:\n\n- The resource's allow policy\n- The resource's deny policies, if any\n- The allow policies of the resource's parent project, folder, and organization, if any\n- The deny policies of the resource's parent project, folder, and organization, if any\n\n\nThe allow and deny policies of parent projects, folders, and organizations\naffect access to a resource\nbecause of [policy inheritance](/iam/docs/policies#inheritance).\nWhen you attach an allow or deny policy to a project, folder, or organization,\nthat policy also applies for all resources inside that project, folder, or\norganization.\n\n\nFor example, if a deny policy for an organization says that a principal can't\nuse a specific permission, then the principal can't use that permission for any\nresource within the organization. This rule applies even if the folders and\nprojects within that organization have more permissive deny policies, or allow\npolicies that give the principal the permission.\n\n\nSimilarly, if an allow policy for a project gives a principal a specific\npermission, then the principal has that permission for any resource within the\nproject, provided that they aren't denied that permission.\n\nThe union of all of these policies is called the *applicable policy* or\n*effective policy* for the resource.\n\nIn Google Cloud, you can get a list of all of the allow and deny policies\nthat affect access to a project by using the `gcloud beta projects\nget-ancestors-iam-policy` command with the `--include-deny` flag. Together,\nthese policies make up the applicable policy for the project. You can\ninvestigate each policy to see how it affects the principal's access. \n\n### gcloud\n\n\nBefore using any of the command data below,\nmake the following replacements:\n\n- \u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e: Your Google Cloud project ID. Project IDs are alphanumeric strings, like `my-project`.\n\n\nExecute the\n\n[`gcloud beta projects get-ancestors-iam-policy`](/sdk/gcloud/reference/beta/projects/get-ancestors-iam-policy)\n\ncommand:\n\n#### Linux, macOS, or Cloud Shell\n\n```bash\ngcloud beta projects get-ancestors-iam-policy PROJECT_ID --include-deny --format=json\n```\n\n#### Windows (PowerShell)\n\n```bash\ngcloud beta projects get-ancestors-iam-policy PROJECT_ID --include-deny --format=json\n```\n\n#### Windows (cmd.exe)\n\n```bash\ngcloud beta projects get-ancestors-iam-policy PROJECT_ID --include-deny --format=json\n```\n\n\nThe response contains the allow and deny policies for the project; any folders that are ancestors\nof the project; and the organization. The following example shows allow policies for the\norganization `1234567890123` and the project `my-project`, as well as a deny\npolicy for the project `my-project`:\n\n```\n[\n {\n \"id\": \"1234567890123\",\n \"policy\": {\n \"bindings\": [\n {\n \"members\": [\n \"group:cloud-admins@example.com\"\n ],\n \"role\": \"roles/iam.denyAdmin\"\n },\n {\n \"members\": [\n \"user:raha@example.com\"\n ],\n \"role\": \"roles/iam.serviceAccountAdmin\"\n }\n ],\n \"etag\": \"BwXW6Eab7TI=\",\n \"version\": 1\n },\n \"type\": \"organization\"\n },\n {\n \"id\": \"my-project\",\n \"policy\": {\n \"bindings\": [\n {\n \"members\": [\n \"group:cloud-admins@example.com\"\n ],\n \"role\": \"roles/owner\"\n }\n ],\n \"etag\": \"BwXXjOM7L6M=\",\n \"type\": \"project\"\n }\n },\n {\n \"id\": \"my-project\",\n \"policy\": {\n \"createTime\": \"2022-02-14T21:46:35.865279Z\",\n \"displayName\": \"My deny policy\",\n \"etag\": \"MTgyMzg2ODcwNTEyMjMxMTM3Mjg=\",\n \"kind\": \"DenyPolicy\",\n \"name\": \"policies/cloudresourcemanager.googleapis.com%2Fprojects%2F123456789012/denypolicies/my-deny-policy\",\n \"rules\": [\n {\n \"denyRule\": {\n \"deniedPermissions\": [\n \"iam.googleapis.com/serviceAccounts.create\"\n ],\n \"deniedPrincipals\": [\n \"user:raha@example.com\"\n ]\n },\n \"description\": \"Prevent service account creation\"\n }\n ],\n \"uid\": \"c83e3dc3-d8a6-6f51-4018-814e9f200b05\",\n \"updateTime\": \"2022-02-14T21:46:35.865279Z\"\n },\n \"type\": \"project\"\n }\n]\n```\n\nIn this example, Raha is granted the Service Account\nAdmin role (`roles/iam.serviceAccountAdmin`) on the organization, but the\nproject has a deny policy that prevents Raha from using the\npermission `iam.googleapis.com/serviceAccounts.create`. As a result, if\nRaha tries to create a service account in the project\n`my-project`, the request will be denied.\n\nIn some cases, you might only need to view the effective allow policy for a\nresource---for example, if your organization doesn't use deny policies. In\nthese cases, you can use the following methods to view the effective allow\npolicy:\n\n- View the resource's IAM allow policy in the\n Google Cloud console. The Google Cloud console automatically shows each\n resource's effective policy.\n\n To learn how to view a resource's IAM allow policy in the\n Google Cloud console, see [View current access](/iam/docs/granting-changing-revoking-access#view-access).\n- Use the Cloud Asset API to get the resource's effective allow policy. To learn\n more, see [Viewing effective IAM policies](/asset-inventory/docs/view-effective-iam-policies).\n\nSearch allow policies\n---------------------\n\nIf you need to locate a specific role binding in an allow policy, you can\nsearch the allow policy.\n\nCloud Asset Inventory lets you search allow policies for role bindings\nthat match the specified parameters. You can use a variety of search parameters,\nincluding the following:\n\n- Resource type\n- Principal type\n- Role\n- Project\n- Folder\n- Organization\n\nFor more information, see [Searching IAM allow policies](/asset-inventory/docs/searching-iam-policies)."]]
