假设您有一个网络配置，其中有三个后端服务，每个服务都有一个安全政策。此外，您还有一个已知是恶意的 IP 地址列表。在每个安全政策中创建 deny 规则时，您可以创建一个地址组，并将其与所有三个安全政策搭配使用，而不是将 IP 地址列表添加到每个安全政策中。然后，每当您创建新的安全政策时，都可以再次使用地址组来制定新规则。
假设您有一个组织，其中包含许多分组到文件夹中的项目，并且您有三个 IP 地址列表，每个列表中的地址只需要访问其中一些文件夹。您可以创建三个组织级地址组（每个 IP 地址列表对应一个），然后创建三个分层安全政策。您可以为每个分层安全政策提供一个针对三个地址组之一进行匹配的 allow 规则，然后将分层安全政策与允许的 IP 地址组需要访问的每个文件夹相关联。
[[["易于理解","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-04。"],[[["\u003cp\u003eAddress groups contain multiple IP addresses or IP ranges, and can be referenced by multiple resources like Cloud NGFW firewall policies or Google Cloud Armor security policies.\u003c/p\u003e\n"],["\u003cp\u003eUpdates made to an address group are automatically applied to all resources that reference it, ensuring consistency across security policies.\u003c/p\u003e\n"],["\u003cp\u003eEach address group is uniquely identified by a URL containing the container type, container ID, location, and the address group's name, and they can be project or organization scoped.\u003c/p\u003e\n"],["\u003cp\u003eAddress groups have a type (IPv4 or IPv6) and capacity, which must be set upon creation and cannot be changed later, with capacity limits varying by the product using the address group.\u003c/p\u003e\n"],["\u003cp\u003eUsing address groups with security policies simplifies configuration by allowing the same list of IP addresses to be shared across multiple policies, but it requires enrollment in Cloud Armor Enterprise.\u003c/p\u003e\n"]]],[],null,["# Address groups overview\n\nAn *address group* contains multiple IP addresses, IP address ranges in CIDR\nformat, or both. Each address group can be used by multiple resources, such as\nrules in Cloud NGFW firewall policies or rules in\nCloud Armor security policies.\n\nUpdates to an address group are automatically propagated to the resources that\nreference the address group. For example, you can create an address group\ncontaining a set of trusted IP addresses. To change the set of trusted IP\naddresses, you update the address group. Your updates to the address group are\nreflected in each associated resource automatically.\n\nSpecifications\n--------------\n\nAddress group resources have the following characteristics:\n\n- Each address group is uniquely identified by a URL with the following elements:\n - **Container type:** Determines the address group type---`organization` or `project`.\n - **Container ID:** ID of the organization or the project.\n - **Location:** Specifies if the address group is a `global` or regional resource (such as `europe-west`).\n - **Name:** The address group name with the following format:\n - A string 1-63 characters long\n - Includes only alphanumeric characters\n - Must not start with a number\n- You can construct a unique URL identifier for an address group in the\n following format:\n\n \u003ccontainerType\u003e/\u003ccontainerId\u003e/locations/\u003clocation\u003e/addressGroups/\u003caddress-group-name\u003e\n\n For example, a `global` address group `example-address-group` in project\n `myproject`has the following unique 4-tuple identifier: \n\n projects/myproject/locations/global/addressGroups/example-address-group\n\n- Each address group has an associated type that can be either IPv4 or IPv6,\n but not both. The address group type cannot be changed later.\n\n- Each IP address or IP range in an address group is referred to as an *item*.\n The number of items that you can add to an address group depends on the\n address group's capacity. You can define the item capacity during address\n group creation. This capacity cannot be changed later. The maximum capacity\n that you can configure for an address group varies depending on the product\n with which you use the address group.\n\n- You must specify the capacity and type when you create an address group. In\n addition, when you use Cloud Armor, you must set the `purpose`\n field to `CLOUD_ARMOR`.\n\n- When you create an address group with a purpose that is *not*\n `CLOUD_ARMOR`, the address group has a maximum capacity of 1,000 IP\n addresses.\n\nTypes of address groups\n-----------------------\n\nAddress groups are classified based on their scope. The scope identifies the level\nat which the address group is applicable in the\n[resource hierarchy](/resource-manager/docs/cloud-platform-resource-hierarchy).\nAddress groups are categorized into the following types:\n\n- [Project-scoped address groups](#project-scoped-address-group)\n- [Organization-scoped address groups](#organization-scoped-address-group)\n\nAn address group can be either project-scoped or organization-scoped, but not\nboth.\n\n### Project-scoped address groups\n\nUse project-scoped address groups when you want to define your own list of IP\naddresses to be used within a project or a network to block or allow a list of\nchanging IP addresses. For example, if you want to define your own threat\nintelligence list and add it to a rule, create an address group with the\nrequired IP addresses.\nThe container type for project-scoped address groups is always set to `project`. For more information about how to create and modify project-scoped address groups, see [Use project-scoped address groups](/armor/docs/address-groups-using#project-scoped-address-group).\n\n### Organization-scoped address groups\n\n|\n| **Preview**\n|\n|\n| This product or feature is subject to the \"Pre-GA Offerings Terms\" in the General Service Terms section\n| of the [Service Specific Terms](/terms/service-terms#1).\n|\n| Pre-GA products and features are available \"as is\" and might have limited support.\n|\n| For more information, see the\n| [launch stage descriptions](/products#product-launch-stages).\nUse organization-scoped address groups when you want to define a central list of IP addresses that can be used in high-level rules to provide consistent control for the entire organization and reduce the overhead for individual network and project owners to maintain common lists, such as trusted services and internal IP addresses.\n\n\u003cbr /\u003e\n\nThe container type for organization-scoped address groups is always set to\n`organization`. For more information about how to create and modify\norganization-scoped address groups, see\n[Use organization-scoped address groups](/armor/docs/address-groups-using#organization-scoped-address-group).\n\n\nHow address groups work with security policies\n----------------------------------------------\n\nAddress groups simplify the configuration and maintenance of security policies\nbecause you can share each list of IP addresses across many security policies.\nConsider the following additional specifications when you use address groups\nwith security policies:\n\n- Address groups are only available for globally scoped [backend security policies](/armor/docs/security-policy-overview#backend-policies).\n- Organization-scoped address groups are available for both service-level security policies and hierarchical security policies.\n- The capacity of an address group is added to the total attribute count of the security policy where the address group is used. Make sure that you set the capacity to an appropriate value based on your use case.\n- To use address groups, your project must be enrolled in [Cloud Armor Enterprise](/armor/docs/armor-enterprise-overview). If you downgrade to standard billing, you can't create new address groups or modify existing address groups. You also can't create rules that reference an exsisting address group, and your security policies that reference address groups are frozen. This means that they are still active, but that you can't modify them until you delete all of the rules that reference an address group.\n\nWe recommend that you view the [quotas](/armor/quotas#address-group-quotas)\nand [limits](/armor/quotas#address-group-limits) for address groups.\n\nIn addition to configuring organization-scoped address groups for your backend\nsecurity policies, you can configure organization-scoped address groups for your\nhierarchical security policies. You can't use project-scoped address groups in any\nsecurity policies outside of the project in which they exist, but you can share\norganization-scoped address groups with security policies across your entire\norganization; this makes organization-scoped address groups with security\npolicies especially helpful when you use them with hierarchical security policies. For\nmore information about hierarchical security policies, see the\n[Hierarchical security policies overview](/armor/docs/hierarchical-policies-overview).\n\n### Examples\n\nThe following examples demonstrate how you might use address groups to help\nyou configure security policies:\n\n- Imagine that you have a network configuration in which you have three backend services, each of which has one security policy. In addition, you have a list of IP addresses that you know are malicious. When you create a `deny` rule in each security policy, you can create one address group and use it with all three security policies instead of adding the list of IP addresses to each security policy. Then, whenever you create a new security policy, you can use the address group again to make new rules.\n- Imagine that you have an organization with many projects that are grouped into folders, and you have three lists of IP addresses that each need access to only some of these folders. You can create three organization-scoped address groups, one for each list of IP addresses, and then create three hierarchical security policies. You can give each hierarchical security policy an `allow` rule that matches on one of the three address groups, then associate the hierarchical security policy with each folder that the allowed IP address group needs to access.\n\nWhat's next\n-----------\n\n- [Configure address groups](/armor/docs/address-groups-using)."]]
