如需允许从部署在其他项目或组织中的专用资源进行边界访问，源项目中必须有一个 Cloud NAT 网关。Cloud NAT 与专用 Google 访问通道集成，可在资源的子网上自动启用专用 Google 访问通道，并将流量保持在 Google APIs 和服务的内部网络中，而不是通过 Cloud NAT 网关的外部 IP 地址路由到互联网。由于流量在内部 Google 网络中路由，因此 AuditLog 对象的 RequestMetadata.caller_ip 字段会被隐去为 gce-internal-ip。请勿在基于 IP 地址的许可名单的访问权限级别中使用 Cloud NAT 网关外部 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。"],[],[],null,["# Allow access to protected resources from outside a perimeter\n\nTo grant controlled access to protected Google Cloud resources in\nservice perimeters from outside a perimeter, use **access levels**.\n\nAn access level defines a set of attributes that a request must meet for the request\nto be honored. Access levels can include various criteria, such as IP address and\nuser identity.\n\nFor a detailed overview of access levels, read the\n[Access Context Manager overview](/access-context-manager/docs/overview).\n\nBefore you use access levels in your perimeter, consider the following:\n\n- Access levels and [ingress rules](/vpc-service-controls/docs/ingress-egress-rules#ingress-rules-reference)\n work together to control incoming traffic to a perimeter.\n VPC Service Controls allows a request if it satisfies the conditions of\n either the access level or the ingress rule.\n\n- If you add multiple access levels to a service perimeter,\n VPC Service Controls allows a request if it satisfies the conditions of\n any one of the access levels.\n\nLimitations of using access levels with VPC Service Controls\n------------------------------------------------------------\n\nWhen using access levels with Service Controls, certain limitations apply:\n\n- Access levels only allow requests from *outside* a perimeter for the\n resources of a protected service *inside* a perimeter.\n\n You cannot use access levels to allow requests from a protected resource\n *inside* a perimeter to resources *outside* the perimeter. For example,\n a Compute Engine client within a service perimeter calling a\n Compute Engine `create` operation where the image resource is outside the\n perimeter. To allow access from a protected resource inside a perimeter to\n resources outside the perimeter, use an [egress policy](/vpc-service-controls/docs/configuring-ingress-egress-policies).\n- Even though access levels are used to allow requests from outside a service perimeter,\n you cannot use access levels to allow requests from *another* perimeter to a protected resource in your\n perimeter. To allow requests from *another* perimeter to protected resources in\n your perimeter, the other perimeter must use an [egress policy](/vpc-service-controls/docs/configuring-ingress-egress-policies).\n For more information, read about\n [requests between perimeters](/vpc-service-controls/docs/troubleshooting#requests-between-perimeters).\n\n- To allow perimeter access from private resources deployed in a\n different project or organization, a Cloud NAT gateway is required\n in the source project. [Cloud NAT](/nat/docs/nat-product-interactions#interaction-pga)\n has an integration with [Private Google Access](/vpc/docs/configure-private-google-access)\n that automatically enables Private Google Access on the resource's\n subnet, and keeps the traffic to Google APIs and services internal,\n as opposed to routing it to the internet using the Cloud NAT\n gateway external IP address. As the traffic is routed within the internal\n Google network, the `RequestMetadata.caller_ip` field of the `AuditLog`\n object is redacted to `gce-internal-ip`. Instead of using the\n Cloud NAT gateway external IP address in the access level for\n [IP-based allowlist](/vpc-service-controls/docs/access-level-design#source-ip),\n configure an ingress rule to allow access based on other attributes such as\n the project or service account.\n\nCreate and manage access levels\n-------------------------------\n\nAccess levels are created and managed using Access Context Manager.\n\n### Create an access level\n\nTo create an access level, read about\n[creating an access level](/access-context-manager/docs/create-basic-access-level)\nin the Access Context Manager documentation.\n\nThe following examples explain how to create an access level using different\nconditions:\n\n- [IP address](/access-context-manager/docs/create-basic-access-level#corporate-network-example)\n- [User and service accounts](/access-context-manager/docs/create-basic-access-level#members-example) (principals)\n- [Device policy](/access-context-manager/docs/access-level-attributes#device-policy)\n\n### Add access levels to service perimeters\n\nYou can add access levels to a service perimeter when creating the perimeter,\nor to an existing perimeter:\n\n- Read about\n [adding access levels when you create a perimeter](/vpc-service-controls/docs/create-service-perimeters#external-access)\n\n- Read about\n [adding access levels to an existing perimeter](/vpc-service-controls/docs/manage-service-perimeters#add-access-level)\n\n### Manage access levels\n\nFor information about listing, modifying, and deleting existing access levels,\nread [Managing access levels](/access-context-manager/docs/manage-access-levels).\n\nWhat's next\n-----------\n\n- [Creating an access level](/access-context-manager/docs/create-basic-access-level)\n\n*[VPC]: Virtual Private Cloud"]]
