액세스 수준과 인그레스 규칙은 함께 작동하여 경계로 들어오는 트래픽을 제어합니다.
VPC 서비스 제어는 액세스 수준 또는 인그레스 규칙의 조건을 충족하는 경우 요청을 허용합니다.
서비스 경계에 여러 액세스 수준을 추가하면 VPC 서비스 제어는 액세스 수준 중 하나의 조건을 충족하는 경우 요청을 허용합니다.
VPC 서비스 제어에서 액세스 수준 사용 시 제한사항
VPC 서비스 제어에서 액세스 수준을 사용할 때 다음과 같은 특정 제한사항이 적용됩니다.
액세스 수준을 사용하여 경계 내에서 보호되는 서비스의 리소스에 대한 경계 외부의 요청을 허용할 수 있습니다.
액세스 수준을 사용하여 경계 외부에 있는 리소스의 경계 내에서 보호되는 리소스의 요청을 허용할 수 없습니다. 예를 들어 서비스 경계 내에 있는 Compute Engine 클라이언트에서 이미지 리소스가 경계 외부에 있는 Compute Engine create 작업을 호출합니다. 경계 내부의 보호되는 리소스에서 경계 외부의 리소스에 대한 액세스를 허용하려면 이그레스 정책을 사용합니다.
액세스 수준은 서비스 경계 외부의 요청을 허용하는 데 사용되지만 다른 경계에서 경계에 있는 보호된 리소스에 대한 요청을 허용하는 액세스 수준을 사용할 수 없습니다. 다른 경계에서 경계에 있는 보호되는 리소스에 대한 요청을 허용하려면 다른 경계에서 이그레스 정책을 사용해야 합니다.
자세한 내용은 경계 간 요청을 참조하세요.
다른 프로젝트 또는 조직에 배포된 비공개 리소스에서 경계 액세스를 허용하려면 소스 프로젝트에 Cloud NAT 게이트웨이가 필요합니다. Cloud NAT는 비공개 Google 액세스와 통합되어 리소스의 서브넷에서 비공개 Google 액세스를 자동으로 사용 설정하고 Cloud NAT 게이트웨이 외부 IP 주소를 사용하여 트래픽을 인터넷으로 라우팅하는 대신 Google API 및 서비스로의 트래픽을 내부로 유지합니다. 트래픽이 내부 Google 네트워크 내에서 라우팅되므로 AuditLog 객체의 RequestMetadata.caller_ip 필드가 gce-internal-ip로 수정됩니다. IP 기반 허용 목록의 액세스 수준에서 Cloud NAT 게이트웨이 외부 IP 주소를 사용하는 대신 프로젝트 또는 서비스 계정과 같은 다른 속성을 기반으로 액세스를 허용하도록 인그레스 규칙을 구성합니다.
액세스 수준 만들기 및 관리
액세스 수준은 Access Context Manager를 사용하여 생성되고 관리됩니다.
액세스 수준 만들기
액세스 수준을 만들려면 Access Context Manager 문서에서 액세스 수준 만들기를 읽어보세요.
[[["이해하기 쉬움","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"]]
