Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Cette page explique comment résoudre les problèmes liés aux stratégies d'autorisation, de refus et de limite d'accès des comptes principaux dans Identity and Access Management (IAM).
Utiliser Policy Troubleshooter
Si vous devez résoudre des problèmes d'accès pour un compte principal spécifique, utilisez l'outil Policy Troubleshooter pour IAM.
Policy Troubleshooter vous aide à déterminer si un compte principal peut accéder à une ressource. À l'aide d'un compte principal, d'une ressource et d'une autorisation, Policy Troubleshooter examine les stratégies d'autorisation, les stratégies de refus et les stratégies de limite d'accès des comptes principaux (PAB, Principal Access Boundary) qui ont un impact sur l'accès du compte principal.
Il vous indique ensuite si, en fonction de ces stratégies, le compte principal peut utiliser l'autorisation spécifiée pour accéder à la ressource. Il répertorie également les stratégies pertinentes et explique leur impact sur l'accès du compte principal.
Pour apprendre à utiliser Policy Troubleshooter pour résoudre les problèmes liés aux stratégies d'autorisation, aux stratégies de refus et aux stratégies de limites d'accès des comptes principaux, consultez Résoudre les problèmes d'autorisations IAM.
Afficher toutes les stratégies d'autorisation et de refus qui s'appliquent à une ressource
Dans Google Cloud, les stratégies d'autorisation et de refus suivantes affectent l'accès à une ressource :
La stratégie d'autorisation de la ressource
Les règles de refus de la ressource, le cas échéant
Les stratégies d'autorisation du projet, du dossier et de l'organisation parent de la ressource, le cas échéant
Les stratégies de refus du projet, du dossier et de l'organisation parent de la ressource, le cas échéant
Les stratégies d'autorisation et de refus des projets, dossiers et organisations parents affectent l'accès à une ressource en raison de l'héritage des stratégies.
Lorsque vous associez une stratégie d'autorisation ou de refus à un projet, un dossier ou une organisation, cette stratégie s'applique également à toutes les ressources de ce projet, ce dossier ou cette organisation.
Par exemple, si une stratégie de refus pour une organisation indique qu'un compte principal ne peut pas utiliser une autorisation spécifique, le compte principal ne peut utiliser cette autorisation sur aucune ressource de l'organisation. Cette règle s'applique même si les dossiers et les projets de cette organisation sont associés à des stratégies de refus plus permissives ou à des stratégies d'autorisation qui accordent cette autorisation au compte principal.
De même, si une stratégie d'autorisation pour un projet accorde une autorisation spécifique à un compte principal, celui-ci dispose de cette autorisation pour n'importe quelle ressource du projet, à condition que cette autorisation ne lui soit pas refusée.
L'union de toutes ces stratégies est appelée stratégie applicable ou stratégie en vigueur pour la ressource.
Dans Google Cloud, vous pouvez obtenir la liste de toutes les stratégies d'autorisation et de refus qui affectent l'accès à un projet à l'aide de la commande gcloud beta projects
get-ancestors-iam-policy avec l'option --include-deny. Utilisées conjointement, ces stratégies constituent la stratégie applicable au projet. Vous pouvez examiner chaque stratégie pour voir comment elle affecte l'accès du compte principal.
gcloud
Avant d'utiliser les données de la commande ci-dessous, effectuez les remplacements suivants :
PROJECT_ID : ID de votre projet Google Cloud . Les ID de projet sont des chaînes alphanumériques, telles que my-project.
La réponse contient les règles d'autorisation et de refus du projet. Tous les dossiers ancêtres du projet et à l'organisation. L'exemple suivant présente des règles d'autorisation pour l'organisation 1234567890123 et le projet my-project, ainsi qu'une règle de refus pour le projet my-project:
Dans cet exemple, le rôle Administrateur de compte de service (roles/iam.serviceAccountAdmin) est attribué à Raha au niveau de l'organisation, mais le projet dispose d'une règle de refus qui empêche Raha d'utiliser l'autorisation iam.googleapis.com/serviceAccounts.create. Par conséquent, si Raha tente de créer un compte de service dans le projet my-project, la requête est refusée.
Dans certains cas, vous devrez peut-être afficher uniquement la stratégie d'autorisation applicable pour une ressource, par exemple si votre organisation n'utilise pas de stratégies de refus. Dans ce cas, vous pouvez utiliser les méthodes suivantes pour afficher la stratégie d'autorisation applicable :
Affichez la stratégie IAM de la ressource dans la consoleGoogle Cloud . La console Google Cloud affiche automatiquement la stratégie applicable de chaque ressource.
Pour savoir comment afficher la stratégie IAM d'une ressource dans la consoleGoogle Cloud , consultez Afficher l'accès actuel.
Utilisez l'API Cloud Asset pour obtenir la stratégie applicable de la ressource. Pour en savoir plus, consultez la page Afficher des stratégies IAM applicables.
Rechercher des stratégies d'autorisation
Si vous devez localiser une liaison de rôle spécifique dans une stratégie d'autorisation, vous pouvez effectuer une recherche dans la stratégie d'autorisation.
L'inventaire des éléments cloud vous permet de rechercher des stratégies IAM pour des liaisons de rôles correspondant aux paramètres spécifiés. Vous pouvez utiliser divers paramètres de recherche, y compris les suivants :
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/11 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/09/11 (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)."]]
