对于 IAM 资源（包括 IAMPolicy、IAMPartialPolicy、IAMPolicyMember 和 IAMAuditConfig），您无需提供作用域。而是通过 spec.resourceRef 字段将这些资源附加到其他资源。 Google Cloud 此其他 Google Cloud 资源可以是 PubSubTopic、SpannerInstance，甚至是项目、文件夹、组织等“作用域”，它们本身都被建模为 Google Cloud 资源。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-09-02。"],[[["\u003cp\u003eConfig Connector manages Google Cloud resources at project, folder, or organization levels, determining the scope through either a resource spec field or an annotation.\u003c/p\u003e\n"],["\u003cp\u003eResources can be scoped using \u003ccode\u003eprojectRef\u003c/code\u003e, \u003ccode\u003efolderRef\u003c/code\u003e, or \u003ccode\u003eorganizationRef\u003c/code\u003e fields, or via annotations like \u003ccode\u003ecnrm.cloud.google.com/project-id\u003c/code\u003e.\u003c/p\u003e\n"],["\u003cp\u003eScope-defining fields are recommended over annotations for making resource specs self-contained and enabling single-step scope creation, and are preferred when available.\u003c/p\u003e\n"],["\u003cp\u003eOnce a resource's scope is set, it's immutable, and changing the scope requires deleting the resource and creating it anew.\u003c/p\u003e\n"],["\u003cp\u003eSome resources don't require scope specification, such as those linked to billing accounts or IAM resources attached to other Google Cloud resources.\u003c/p\u003e\n"]]],[],null,["# Organizing your resources\n=========================\n\n*** ** * ** ***\n\nOverview\n--------\n\nConfig Connector can create and manage Google Cloud resources at the project-level, folder-level,\nor organization-level scope. Config Connector needs to determine:\n\n- Whether to create the resource at the project-level, folder-level, or organization-level.\n- Which project, folder, or organization to use.\n\nAs a result, Config Connector first checks for a scope-defining\nfield in your resource spec, if not found, then checks for a scope-defining\nannotation. Most Google Cloud resources can be created at only the\nproject-level.\n\nOnce a resource is successfully created, regardless of how the scope is\nset, the field or annotation becomes immutable. To change the\nscope of a resource, you must delete the current resource and create a\nnew resource in a different project, folder, or organization scope.\n\n### Scope-defining field\n\nA scope-defining resource spec field is part of the resource's spec and can\nbe set only in the resource's configuration. It follows the naming convention of\n\u003cvar class=\"readonly\" translate=\"no\"\u003eSCOPE\u003c/var\u003eRef. Depending on the resource type,\nthe schema of the spec may contain at least one of the following fields:\n\n- `projectRef`\n- `folderRef`\n- `organizationRef`\n\n### Scope-defining annotation\n\nYou can define a scope-defining annotation in the resource's configuration\nor in the Kubernetes namespace which contains the resource. There are three types of scope-defining annotations depending on the resource type:\n\n- `cnrm.cloud.google.com/project-id`\n- `cnrm.cloud.google.com/folder-id`\n- `cnrm.cloud.google.com/organization-id`\n\nMost Config Connector resources support scope-defining fields. We recommend\nfields over scope-defining annotations because a scope-defining field makes the\nresource spec more self-contained and enables the creation of a scope and its\ncontained resources in one step. For resources that do not support\nscope-defining fields, you can either supply\nthe scope-defining annotation in their configuration, or default the\nannotation for all resources in a particular namespace by annotating the\nnamespace. The namespace annotation is ignored if the resource has the\nscope-defining annotation directly in its configuration.\n| **Warning:** Using the namespace annotation is a convenient way to specify default scope for all resources under the same namespace, but it may cause performance issues when managing a large number of resources under one Kubernetes namespace.\n\nExceptions\n----------\n\nIf the scope concept does not apply to a Config Connector resource, you do not need to specify a project, folder, or organization scope.\nSpecifically if a resource listed in the\n[resource reference page](/config-connector/docs/reference/overview) does not have a scope-defining field or a scope-defining annotation,\nyou do not need to add a scope.\n\nSome resources, like [BillingBudgetsBudget](/config-connector/docs/reference/resource-docs/billingbudgets/billingbudgetsbudget)\nare bound to a Google Cloud billing account, and requires you to specify\nthe billing account information instead.\n\nIAM resources, including [IAMPolicy](/config-connector/docs/reference/resource-docs/iam/iampolicy),\n[IAMPartialPolicy](/config-connector/docs/reference/resource-docs/iam/iampartialpolicy),\n[IAMPolicyMember](/config-connector/docs/reference/resource-docs/iam/iampolicymember)\nand [IAMAuditConfig](/config-connector/docs/reference/resource-docs/iam/iamauditconfig) do not require you to provide a scope.\nInstead, these resources are attached to another Google Cloud resource through the `spec.resourceRef`\nfield. This other Google Cloud resource can be a `PubSubTopic`, a `SpannerInstance`\nor even a \"scope\" like project, folder, organization, which are themselves modeled as a Google Cloud resource.\n\nWhat's next\n-----------\n\nSee how to apply the following types of scopes:\n\n- [Project-scoped resources](/config-connector/docs/how-to/organizing-resources/project-scoped-resources)\n\n- [Folder-scoped\n resources](/config-connector/docs/how-to/organizing-resources/folder-scoped-resources)\n\n- [Organization-scoped\n resources](/config-connector/docs/how-to/organizing-resources/organization-scoped-resources)"]]
