[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["わかりにくい","hardToUnderstand","thumb-down"],["情報またはサンプルコードが不正確","incorrectInformationOrSampleCode","thumb-down"],["必要な情報 / サンプルがない","missingTheInformationSamplesINeed","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-09-04 UTC。"],[[["\u003cp\u003eScoped policies allow delegation of VPC Service Controls perimeter and access level administration to folder-level and project-level administrators, alongside an organization-level access policy.\u003c/p\u003e\n"],["\u003cp\u003eOrganization-level administrators can create, modify, and delete scoped policies, but delegated administrators can only manage the specific policy assigned to them, not the organization's policy.\u003c/p\u003e\n"],["\u003cp\u003eScoped policies restrict resources within the specified scope, such as a folder or project, meaning service perimeters can only secure resources within that scope, and access levels are only visible within the scope.\u003c/p\u003e\n"],["\u003cp\u003eEach folder or project can only have one scoped policy, and when a folder or project is deleted, the associated scoped policy is also deleted, with projects that are moved to different locations needing to be recreated and re-scoped.\u003c/p\u003e\n"],["\u003cp\u003eIf an organization-level access policy does not exist, scoped policies created at the folder or project level will not function, highlighting the dependency on an organizational access policy.\u003c/p\u003e\n"]]],[],null,["# Scoped policies are access policies that are scoped to specific folders or projects\nalongside an access policy that you can apply to the entire organization. You can\nuse scoped policies to delegate administration of VPC Service Controls perimeters\nand access levels to folder-level and project-level administrators.\n\nOrganizations can only have one access policy at the organizational level, and you\ncan apply the organizational-level access policy to any folder or project in your\norganization.\n\nThere might be instances when you want to delegate the management of a policy for a\nsubset of an organization's resources, such as a folder, to a delegated administrator.\nYou can create access policies that are scoped to specific folders or projects\nalongside an access policy that can apply to the entire organization. To delegate\nadministration of VPC Service Controls perimeters and access levels to folder-level and\nproject-level administrators, you can use scoped policies.\n\nWhen you delegate administration of a scoped policy, the delegated administrators can\nmodify or read that specific policy and not the organization's Access Context Manager policy.\nThe scoped policies limit the resources that can be restricted in a VPC Service Controls perimeter, and the visibility of any access levels.\n\nScoped policies management\n--------------------------\n\nAs an organization-level Access Context Manager administrator, you can create, modify,\nand delete scoped policies. You can specify Identity and Access Management (IAM) bindings on\nAccess Context Manager policy directly, and allow further delegation of\nAccess Context Manager policy administration to other users in the organization. A\nscoped policy administrator can configure service perimeters and access levels in\npolicies. However, a scoped policy administrator cannot create a new policy or change\nthe scope of the policy to apply to another folder or project.\n| **Warning:** If an organization-level access policy doesn't exist for your organization, scoped policies that you create at the folder or project-level will not operate.\n\nHere is a sequence of how administrators manage the scoped policies:\n\n1. The organization-level administrator creates a new access policy with a scope\n field referencing a specific folder or project.\n\n2. The organization-level administrator assigns IAM permissions to the delegated\n administrator directly on the access policy resource. The delegated administrator\n now has permissions on the scoped policy but does not have permissions on any\n other policy unless the organization-level administrator explicitly assigns them\n to the delegated administrator.\n\n3. The delegated administrator can now edit the policy to configure access levels\n and service perimeters. The delegated administrator can also grant\n IAM permissions on that policy to any other user.\n\nWhen you delete a folder or a project, the policy that has the deleted folder or project\nas its scope is also deleted. Also, if you move a project to another node in the\norganization hierarchy, the policy scoped to the project is not automatically modified.\nYou must delete the policy associated with the project, and then recreate the policy\nand specify the scope.\n\nScoped policies hierarchy\n-------------------------\n\nThe organization resource is the root node of the Google Cloud resource hierarchy and\nall resources that belong to an organization exist as children of the organization node.\nFolders are a grouping mechanism on top of projects. Folders and projects\nexist as child nodes of the organization resource.\n\nThe following diagram shows an example organization that contains folders for each\ndepartment, and the folders contain dev, test, and production projects.\n\nIn the example organization, the following constraints apply to a service perimeter\nor an access level in a scoped policy:\n\n- Service perimeters in a scoped policy can only restrict resources that exist\n in the scope of that policy. For example, a service perimeter in a policy scoped\n to the engineering folder can secure the example-dev, example-prod, and example-test\n projects because the projects are in the engineering folder.\n\n If the scoped policy applies to the sales folder, then service perimeters in\n that policy cannot secure any of example-dev, example-prod, and example-test\n projects. However, the service perimeter in the scoped policy can allow access\n to projects in other folders by using ingress and egress rules.\n- Access levels in a scoped policy are only visible within the scope of the policy. If\n you create an access level in the policy scoped to the engineering folder, then only\n service perimeters and access levels in the engineering folder can use it. Service\n perimeters and access levels in other folders cannot use the access level defined in\n the engineering folder.\n\nA location, such as a folder, in the example.com organization resource hierarchy\ncan have multiple policies that contain an access level or service perimeter. When\nmultiple policies exist, a request for resources in the example.com organization\nis evaluated based on the following rules:\n\n- A policy can contain only one scope, such as a folder, but you can create a\n policy for each level of an organization. For example, if the scope of\n policy 1 is the engineering folder, you cannot set the engineering folder as the\n scope of any other policy. You can set another policy with the scope set to the\n child of the engineering folder, such as example-prod.\n\n- If the scope of a policy applies to a project or a parent of the project,\n you can add the project to the policy. However, a project can be a member\n of only one service perimeter across all policies. For example, A policy with\n scope set to the organization example.com can define a service perimeter with\n example-dev. A policy with scope set to the engineering folder or scope set to\n the example-dev project can also add the example-dev project to a perimeter\n defined within either of them. However, only one of those three policies can\n contain this project.\n\nWhat's next\n-----------\n\n- [Create an access policy](/access-context-manager/docs/create-access-policy)"]]
