Zugriff auf geschützte Ressourcen von außerhalb eines Perimeters zulassen
Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Mithilfe von Zugriffsebenen können Sie kontrollierten Zugriff auf geschützte Google Cloud Ressourcen in Dienstperimetern von außerhalb eines Perimeters gewähren.
Eine Zugriffsebene definiert eine Reihe von Attributen, die eine Anfrage erfüllen muss, damit sie berücksichtigt wird. Zugriffsebenen können verschiedene Kriterien berücksichtigen, z. B. IP-Adresse und Nutzeridentität.
Eine detaillierte Übersicht über Zugriffsebenen finden Sie in der Beschreibung zu Access Context Manager.
Bevor Sie Zugriffsebenen in Ihrem Perimeter verwenden, sollten Sie Folgendes beachten:
Zugriffsebenen und Eingangsregeln werden gemeinsam verwendet, um den eingehenden Traffic zu einem Perimeter zu steuern.
VPC Service Controls erlaubt eine Anfrage, wenn sie die Bedingungen der Zugriffsebene oder der Eingangsregel erfüllt.
Wenn Sie einem Dienstperimeter mehrere Zugriffsebenen hinzufügen, erlaubt VPC Service Controls eine Anfrage, wenn sie die Bedingungen einer der Zugriffsebenen erfüllt.
Einschränkungen bei der Verwendung von Zugriffsebenen mit VPC Service Controls
Bei der Verwendung von Zugriffsebenen mit VPC Service Controls gelten bestimmte Einschränkungen:
Zugriffsebenen erlauben für die Ressourcen eines geschützten Dienstes innerhalb eines Perimeters nur Anfragen von außerhalb eines Perimeters.
Sie können keine Zugriffsebenen verwenden, um Anfragen von einer geschützten Ressource innerhalb eines Perimeters für Ressourcen außerhalb des Perimeters zuzulassen. Beispiel: Ein Compute Engine-Client innerhalb eines Dienstperimeters ruft einen create-Vorgang von Compute Engine auf, wobei sich die Image-Ressource außerhalb des Perimeters befindet. Verwenden Sie eine Richtlinie für ausgehenden Traffic, um den Zugriff von einer geschützten Ressource innerhalb eines Perimeters auf Ressourcen außerhalb des Perimeters zuzulassen.
Zugriffsebenen können zwar verwendet werden, um Anfragen von außerhalb eines Dienstperimeters zuzulassen, sie können jedoch nicht verwendet werden, um Anfragen eines anderen Perimeters an eine geschützte Ressource in Ihrem Perimeter zuzulassen. Damit Anfragen von einem anderen Perimeter an geschützte Ressourcen in Ihrem Perimeter zugelassen werden, muss der andere Perimeter eine Richtlinie für ausgehenden Traffic verwenden.
Weitere Informationen finden Sie unter Anfragen zwischen Perimetern.
Um den Perimeterzugriff von privaten Ressourcen zu ermöglichen, die in einem anderen Projekt oder einer anderen Organisation bereitgestellt werden, ist im Quellprojekt ein Cloud NAT-Gateway erforderlich. Cloud NAT ist in Privaten Google-Zugriff integriert. Dadurch wird der privater Google-Zugriff automatisch im Subnetzwerk der Ressource aktiviert und der Traffic zu Google APIs und ‑Diensten bleibt intern, anstatt über die externe IP-Adresse des Cloud NAT-Gateways an das Internet weitergeleitet zu werden. Da der Traffic innerhalb des internen Google-Netzwerks weitergeleitet wird, wird das Feld RequestMetadata.caller_ip des AuditLog-Objekts zu gce-internal-ip entfernt. Anstatt die externe IP-Adresse des Cloud NAT-Gateways in der Zugriffsebene für die IP-basierte Zulassungsliste zu verwenden, konfigurieren Sie eine Ingress-Regel, um den Zugriff basierend auf anderen Attributen wie dem Projekt- oder Dienstkonto zuzulassen.
Zugriffsebenen erstellen und verwalten
Zugriffsebenen werden mit Access Context Manager erstellt und verwaltet.
Zugriffsebene erstellen
Informationen dazu, wie Sie eine Zugriffsebene erstellen, entnehmen Sie der Dokumentation zu Access Context Manager.
In den folgenden Beispielen wird erläutert, wie Sie eine Zugriffsebene für zwei Kriterien erstellen:
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 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"]]
