Autoriser l'accès aux ressources protégées depuis l'extérieur d'un périmètre
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Pour accorder un accès contrôlé aux ressources Google Cloud protégées dans des périmètres de service depuis l'extérieur d'un périmètre, utilisez des niveaux d'accès.
Un niveau d'accès définit un ensemble d'attributs qui doivent être respectés avant qu'une requête ne soit honorée. Les niveaux d'accès peuvent prendre en compte divers critères, tels que l'adresse IP et l'identité de l'utilisateur.
Avant d'utiliser des niveaux d'accès dans votre périmètre, tenez compte des points suivants:
Les niveaux d'accès et les règles d'entrée fonctionnent ensemble pour contrôler le trafic entrant vers un périmètre.
VPC Service Controls autorise une requête si elle répond aux conditions du niveau d'accès ou de la règle d'entrée.
Si vous ajoutez plusieurs niveaux d'accès à un périmètre de service, VPC Service Controls autorise une requête si elle répond aux conditions de l'un des niveaux d'accès.
Limites d'utilisation des niveaux d'accès avec VPC Service Controls
Lorsque vous utilisez des niveaux d'accès avec VPC Service Controls, certaines limites s'appliquent :
Les niveaux d'accès n'autorisent que les requêtes provenant de l'extérieur d'un périmètre pour les ressources d'un service protégé situé à l'intérieur d'un périmètre.
Vous ne pouvez pas utiliser les niveaux d'accès pour autoriser des requêtes provenant d'un service protégé situé à l'intérieur d'un périmètre pour des ressources situées à l'extérieur du périmètre. Par exemple, un client Compute Engine dans un périmètre de service appelant une opération Compute Engine create, pour laquelle la ressource d'image se trouve en dehors du périmètre. Pour autoriser l'accès d'une ressource protégée à l'intérieur d'un périmètre à des ressources extérieures au périmètre, utilisez une règle de sortie.
Même si les niveaux d'accès sont utilisés pour autoriser les requêtes provenant de l'extérieur d'un périmètre de service, vous ne pouvez pas les utiliser pour autoriser les requêtes provenant d'un autre périmètre vers une ressource protégée dans votre périmètre. Pour autoriser les requêtes d'un autre périmètre aux ressources protégées de votre périmètre, l'autre périmètre doit utiliser une règle de sortie.
Pour en savoir plus, consultez la section Requêtes entre périmètres.
Pour autoriser l'accès au périmètre à partir de ressources privées déployées dans un autre projet ou organisation, une passerelle Cloud NAT est requise dans le projet source. Cloud NAT est intégré à l'accès privé à Google, ce qui active automatiquement l'accès privé à Google sur le sous-réseau de la ressource et maintient le trafic vers les API et services Google en interne, au lieu de le router vers Internet à l'aide de l'adresse IP externe de la passerelle Cloud NAT. Comme le trafic est acheminé dans le réseau Google interne, le champ RequestMetadata.caller_ip de l'objet AuditLog est masqué en gce-internal-ip. Au lieu d'utiliser l'adresse IP externe de la passerelle Cloud NAT dans le niveau d'accès de la liste d'autorisation basée sur l'adresse IP, configurez une règle d'entrée pour autoriser l'accès en fonction d'autres attributs tels que le projet ou le compte de service.
Créer et gérer des niveaux d'accès
Les niveaux d'accès sont créés et gérés à l'aide d'Access Context Manager.
Créer un niveau d'accès
Pour créer un niveau d'accès, consultez la section Créer un niveau d'accès de la documentation d'Access Context Manager.
Les exemples suivants expliquent comment créer un niveau d'accès en utilisant différentes conditions :
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/04 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 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"]]
