Auf dieser Seite finden Sie das folgende Beispiel für die Verwendung von Identitätsgruppen in Regeln für eingehenden und ausgehenden Traffic:
Cloud Run-Zugriff für Mitglieder einer Identitätsgruppe über das Internet und für bestimmte Dienstkonten aus einem IP-Adressbereich auf der Zulassungsliste erlauben
Cloud Run-Zugriff für Mitglieder einer Identitätsgruppe und für bestimmte Dienstkonten gewähren
Das folgende Diagramm zeigt einen Nutzer aus einer bestimmten Identitätsgruppe, der über den IP-Adressbereich auf der Zulassungsliste auf Cloud Run innerhalb eines Dienstperimeters zugreift:
Abbildung 1. Ein Beispiel für die Bereitstellung von Cloud Run-Zugriff mit einer Identitätsgruppe.
Angenommen, Sie haben den folgenden Dienstperimeter definiert:
Wenn Sie Details zu einem vorhandenen Dienstperimeter in Ihrer Organisation aufrufen möchten, beschreiben Sie den Dienstperimeter mit dem Befehl der gcloud CLI.
In diesem Beispiel wird außerdem davon ausgegangen, dass Sie die folgenden Ressourcen definiert haben:
Eine Identitätsgruppe namens allowed-users@example.com mit Nutzern, denen Sie innerhalb des Perimeter Zugriff auf Cloud Run gewähren möchten.
Eine Zugriffsebene namens CorpDatacenters in derselben Zugriffsrichtlinie wie der Dienstperimeter. CorpDatacenters enthält einen IP-Adressbereich der Unternehmensrechenzentren, von denen Anfragen von Dienstkonten stammen können.
Die folgende Ingress-Richtlinie ingress.yaml erlaubt Cloud Run-Zugriff auf bestimmte Nutzerkonten, die zur Gruppe allowed-users@example.com gehören, und bestimmte Dienstkonten, die auf den IP-Adressbereich der Zulassungsliste beschränkt sind:
[[["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-08-18 (UTC)."],[],[],null,["# Example of using identity groups and third-party identities in ingress and egress rules\n\nThis page shows how to [use identity groups and third-party identities in\ningress and egress rules](/vpc-service-controls/docs/configure-identity-groups).\n\nThis page contains the following example of using identity groups in ingress\nand egress rules:\n\n- Allow Cloud Run access to an identity group's members through the internet and to specific service accounts from an allowlisted IP address range.\n\nAllow Cloud Run access to an identity group's members and to specific service accounts\n--------------------------------------------------------------------------------------\n\nThe following diagram shows a user from a specific identity group and from the\nallowlisted IP address range accesses Cloud Run inside a service\nperimeter:\n**Figure 1.** An example of providing Cloud Run access using an identity group.\n\nConsider that you have defined the following service perimeter: \n\n```\nname: accessPolicies/222/servicePerimeters/Example\nstatus:\n resources:\n - projects/111\n restrictedServices:\n - run.googleapis.com\n - artifactregistry.googleapis.com\n vpcAccessibleServices:\n enableRestriction: true\n allowedServices:\n - RESTRICTED_SERVICES\ntitle: Example\n```\n\nTo find details about an existing service perimeter in your organization,\n[describe the service\nperimeter](/vpc-service-controls/docs/manage-service-perimeters#list-and-describe)\nusing the gcloud CLI command.\n\nIn this example, we also assume that you have defined the following resources:\n\n- An identity group called `allowed-users@example.com` that has users who you want to provide access to Cloud Run inside the perimeter.\n- An access level called `CorpDatacenters` in the same access policy as the service perimeter. `CorpDatacenters` includes an allowlisted IP address range of the corporate data centers where requests from service accounts can originate from.\n\nThe following ingress policy, `ingress.yaml`, allows Cloud Run\naccess to specific human accounts, who are part of the\n`allowed-users@example.com` group, and specific service accounts, that are\nlimited to the allowlisted IP address range: \n\n```\n- ingressFrom:\n identities:\n - serviceAccount:my-sa@my-project.iam.gserviceaccount.com\n sources:\n - accessLevel: accessPolicies/222/accessLevels/CorpDatacenters\n ingressTo:\n operations:\n - serviceName: run.googleapis.com\n methodSelectors:\n - method: \"*\"\n resources:\n - \"*\"\n- ingressFrom:\n identities:\n - group:allowed-users@example.com\n sources:\n - accessLevel: \"*\"\n ingressTo:\n operations:\n - serviceName: run.googleapis.com\n methodSelectors:\n - method: \"*\"\n resources:\n - \"*\"\n```\n\nTo apply the ingress rule, run the following command: \n\n```\ngcloud access-context-manager perimeters update Example --set-ingress-policies=ingress.yaml\n```\n\nWhat's next\n-----------\n\n- [Configure identity groups and third-party identities in ingress and egress rules](/vpc-service-controls/docs/configure-identity-groups)"]]
