En esta página, se incluye el siguiente ejemplo del uso de grupos de identidad en las reglas de entrada y salida:
Permite que Cloud Run acceda a los miembros de un grupo de identidad a través de Internet y a cuentas de servicio específicas desde un rango de direcciones IP incluidas en la lista de entidades permitidas.
Permite que Cloud Run acceda a los miembros de un grupo de identidad y a cuentas de servicio específicas
En el siguiente diagrama, se muestra un usuario de un grupo de identidad específico y del rango de direcciones IP permitidas que accede a Cloud Run dentro de un perímetro de servicio:
Figura 1. Ejemplo de cómo proporcionar acceso a Cloud Run con un grupo de identidad.
Supongamos que definiste el siguiente perímetro de servicio:
Para encontrar detalles sobre un perímetro de servicio existente en tu organización,
describe el perímetro de servicio
con el comando de gcloud CLI.
En este ejemplo, también suponemos que definiste los siguientes recursos:
Un grupo de identidad llamado allowed-users@example.com que tiene usuarios a los que
deseas proporcionar acceso a Cloud Run dentro del perímetro.
Un nivel de acceso llamado CorpDatacenters en la misma política de acceso que el perímetro de servicio CorpDatacenters incluye un rango de direcciones IP incluidas en la lista de entidades permitidas de los centros de datos corporativos desde los que pueden provenir las solicitudes de las cuentas de servicio.
La siguiente política de entrada, ingress.yaml, permite que Cloud Run acceda a cuentas humanas específicas que forman parte del grupo allowed-users@example.com y a cuentas de servicio específicas, que se limitan al rango de direcciones IP incluidas en la lista de entidades permitidas:
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-09-04 (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)"]]
