[[["わかりやすい","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。"],[],[],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"]]
