Règles d'entrée et de sortie

Cette page décrit les règles d'entrée et de sortie de VPC Service Controls. Grâce à des règles d'entrée et de sortie, VPC Service Controls autorise l'accès vers et depuis des ressources et clients protégés par des périmètres de service.

Les blocs de règles d'entrée et de sortie spécifient la direction de l'accès autorisé en provenance ou à destination de différentes identités et ressources. Les règles d'entrée et de sortie peuvent remplacer et simplifier les cas d'utilisation qui nécessitaient auparavant une ou plusieurs liaisons de périmètre.

Pour savoir comment appliquer des règles d'entrée et de sortie à votre périmètre de service, consultez la page Configurer des règles d'entrée et de sortie.

Vous pouvez configurer des groupes d'identités et des identités tierces ainsi que des rôles IAM (version preview) dans les règles d'entrée et de sortie.

Pour obtenir une liste de cas d'utilisation et d'exemples d'échange de données sécurisé, reportez-vous à la section Échange de données sécurisé à l'aide de règles d'entrée et de sortie.

Pour obtenir une liste de cas d'utilisation et d'exemples d'accès contextuel, consultez la section Accès contextuel à l'aide de règles d'entrée.

Avantages des règles d'entrée et de sortie

  1. Les règles d'entrée et de sortie vous permettent d'échanger des données de manière privée et efficace, au sein d'une même organisation ou entre plusieurs organisations, à l'aide des API de service Google Cloud .
  2. Les règles d'entrée et de sortie vous permettent d'accorder l'accès aux ressources Google Cloudsituées dans un périmètre en fonction du contexte de la requête API :
    1. Appliquez des contraintes sur les types d'identité ou les identités autorisés en fonction du réseau, de l'adresse IP ou de l'appareil source.
    2. Restreignez les API Google Cloud et les méthodes accessibles en fonction du réseau, de l'adresse IP, de l'appareil et du type d'identité source.
  3. Limitez les risques d'exfiltration en définissant exactement quels service, méthodes, projetsGoogle Cloud , réseaux VPC et identités sont autorisés à exécuter l'échange de données.
  4. Accordez un accès en lecture seule aux ensembles de données et aux images externes qui ne sont pas gérés par vos soins.
  5. Assurez-vous que les clients des segments disposant de privilèges inférieurs n'ont pas accès aux ressourcesGoogle Cloud situées dans des segments dotés de privilèges supérieurs, tout en autorisant l'accès dans l'autre sens.
  6. Simplifiez les configurations qui nécessitaient auparavant une ou plusieurs liaisons de périmètre.

Définition de l'entrée et de la sortie

Les définitions de l'entrée et de la sortie sont indépendantes de l'opération appelée sur la ressource. Ainsi, les définitions font référence à la direction de la requête et non à la direction du mouvement de données.

  • Entrée : désigne tout accès aux ressources d'un périmètre de service par un client API extérieur à ce périmètre. Exemple :

    • Un client Cloud Storage situé en dehors d'un périmètre de service, appelant des opérations de lecture, d'écriture ou de copie Cloud Storage sur une ressource Cloud Storage au sein du périmètre.
  • Sortie : désigne tout accès impliquant un client API ou des ressources au sein du périmètre de service, ainsi que des ressources extérieures à ce périmètre. Exemples :

    • Un client Compute Engine, situé dans un périmètre de service, qui appelle une opération Compute Engine create pour laquelle la ressource d'image se trouve en dehors du périmètre.
    • Un client Cloud Storage, situé à l'intérieur ou à l'extérieur du périmètre, qui appelle une commande copy pour laquelle un bucket se trouve à l'intérieur du périmètre et l'autre à l'extérieur.

Modèle de règle

Une règle d'entrée ou de sortie se compose de blocs from et to dans lesquels :

  • from renvoie aux attributs du client API.
  • to renvoie aux attributs des services Google Cloud et des ressources.

Plusieurs règles d'entrée et de sortie peuvent être associées à un même périmètre de service. Un appel de serviceGoogle Cloud est autorisé ou refusé en fonction de la sémantique suivante :

  • Une requête provenant d'un client extérieur au périmètre à destination d'une ressource Google Cloud située dans le périmètre est autorisée si les conditions de la règle d'entrée nécessaire sont remplies.
  • Une requête provenant d'un client situé dans le périmètre à destination d'une ressource Google Cloud extérieure au périmètre est autorisée si les conditions de la règle de sortie nécessaires sont remplies.
  • Un appel d'API impliquant une ressource Google Cloud située dans un périmètre et une ressource Google Cloud extérieure à ce même périmètre est autorisé s'il existe une règle d'entrée satisfaite par le client (si celui-ci ne se trouve pas dans le périmètre) et une règle de sortie satisfaite par la ressource externe.

Exemples de requêtes API autorisées par des règles d'entrée

  • Un client Cloud Storage situé en dehors du périmètre télécharge des objets depuis un bucket Cloud Storage situé dans ce périmètre vers l'ordinateur local (par exemple, à l'aide de la commande gcloud storage cp).
  • Un client BigQuery situé en dehors du périmètre exécute un job BigQuery dans un projet situé dans le même périmètre afin d'interroger un ensemble de données BigQuery se trouvant à l'intérieur du périmètre (à l'aide de la commande bq query, par exemple).
  • La VM Compute Engine d'un réseau VPC extérieur au périmètre écrit dans un bucket Cloud Storage situé dans le périmètre.

Exemples de requêtes API autorisées par des règles de sortie

  • Un client Cloud Storage situé dans le périmètre qui copie des objets entre un bucket Cloud Storage extérieur au périmètre et un bucket à l'intérieur de celui-ci (à l'aide de la commande gcloud storage cp, par exemple).
  • Un client BigQuery situé dans le périmètre exécute un job BigQuery dans un projet extérieur à ce périmètre afin d'interroger un ensemble de données BigQuery se trouvant à l'intérieur du périmètre (à l'aide de la commande bq query, par exemple).

Exemples de requêtes API autorisées par une combinaison de règles d'entrée et de sortie

  • Un client Cloud Storage situé en dehors du périmètre qui copie des objets entre un bucket Cloud Storage extérieur au périmètre et un bucket à l'intérieur de celui-ci (à l'aide de la commande gcloud storage cp, par exemple).
  • Un client BigQuery situé en dehors du périmètre exécute un job BigQuery dans un projet extérieur à ce périmètre afin d'interroger un ensemble de données BigQuery se trouvant à l'intérieur du périmètre (à l'aide de la commande bq query, par exemple).
  • Un client Compute Engine situé en dehors du périmètre qui crée un disque Compute Engine en dehors du périmètre à l'aide d'une clé Cloud KMS située dans le périmètre.

Dans les exemples de BigQuery et Compute Engine, une règle d'entrée ne suffit pas, car le job BigQuery ou le disque Compute Engine se trouvent en dehors du périmètre. Une règle de sortie est requise pour autoriser une requête API qui implique une ressource Google Cloud située dans le périmètre (l'ensemble de données BigQuery ou la clé Cloud KMS) et une ressource extérieure au périmètre (la tâche BigQuery ou le disque Compute Engine).

Requêtes API impliquant plusieurs périmètres de service

Lorsque les ressources consultées et/ou le client API appartiennent à différents périmètres de service, les règles de tous les périmètres concernés doivent autoriser la requête API. Prenons, par exemple, un client et un bucket Cloud Storage a situés dans un périmètre de service A, et un bucket b situé dans un périmètre de service B. Dans cet exemple, pour que le client Cloud Storage puisse copier des objets du bucket a vers le bucket b et du bucket b vers le bucket a, les règles d'entrée et de sortie suivantes sont requises :

  • Une règle de sortie appliquée au périmètre A pour autoriser l'accès au bucket Cloud Storage b
  • Une règle de sortie appliquée au périmètre B pour autoriser l'accès au bucket Cloud Storage a
  • Une règle d'entrée appliquée au périmètre B pour autoriser l'accès au client Cloud Storage situé en dehors du périmètre B.

Documentation de référence sur les règles d'entrée

Les règles d'entrée peuvent être configurées à l'aide de la console Google Cloud , d'un fichier JSON ou d'un fichier YAML. L'exemple suivant utilise le format .yaml :

- ingressFrom:
    identityType: ANY_IDENTITY | ANY_USER_ACCOUNT | ANY_SERVICE_ACCOUNT
    *OR*
    identities:
    - PRINCIPAL_IDENTIFIER
    sources:
    - resource: RESOURCE
      *OR*
    - accessLevel: ACCESS_LEVEL
  ingressTo:
    operations:
    - serviceName: SERVICE
      methodSelectors:
      - method: METHOD
      *OR*
      - permission: PERMISSION
    *OR*
    roles:
    - ROLE_NAME
    resources:
    - projects/PROJECT
  title: TITLE
  • - ingressFrom: (obligatoire) : ouvre le bloc from, qui répertorie les sources et identités extérieures au périmètre qui sont autorisées.

  • identityType: (soit cet attribut, soit l'attribut identities doit être utilisé) : cet attribut définit les types d'identités pouvant être utilisés à partir des sources spécifiées (origine de réseau). Valeurs acceptables : ANY_IDENTITY, ANY_USER_ACCOUNT, ANY_SERVICE_ACCOUNT. ANY_IDENTITY autorise les requêtes provenant de toutes les identités, y compris les requêtes non authentifiées. ANY_USER_ACCOUNT autorise tous les utilisateurs humains et ANY_SERVICE_ACCOUNT autorise tous les comptes de service, mais ni ANY_USER_ACCOUNT ni ANY_SERVICE_ACCOUNT n'autorisent les requêtes non authentifiées.

    Cet attribut ne limite pas les identités en fonction de l'organisation. Par exemple, ANY_SERVICE_ACCOUNT autorise un compte de service de n'importe quelle organisation.

  • identities: (soit cet attribut, soit l'attribut identityType doit être utilisé) : cet attribut ouvre une liste de comptes de service, de comptes utilisateur, de groupes Google ou d'identités tierces qui sont autorisés à accéder aux ressources du périmètre.

  • PRINCIPAL_IDENTIFIER : spécifiez un compte utilisateur, un compte de service, un groupe Google ou une identité tierce auquel vous souhaitez accorder l'accès aux ressources du périmètre. VPC Service Controls n'accepte que les identités suivantes à partir des identifiants de compte principal de l'API IAM v1 :

    • Pour les comptes utilisateur et les comptes de service, utilisez respectivement les formats user:USER_EMAIL_ADDRESS et serviceAccount:SA_EMAIL_ADDRESS.

    • Pour les autres identités, utilisez les formats spécifiés dans la section Groupes d'identités compatibles.

    Pour en savoir plus sur ces identités, consultez Identifiants de compte principal pour les règles d'autorisation.

  • sources: (obligatoire) : cet attribut fait référence à une liste d'origines de réseau. Chaque valeur de la liste est un niveau d'accès ou un projet Google Cloud . Si vous définissez l'attribut accessLevel sur "*", la règle d'entrée autorise l'accès depuis n'importe quelle origine du réseau. Si vous définissez cet attribut sur un projet Google Cloud , la règle d'entrée autorise l'accès depuis un réseau VPC appartenant au projet.

    Cette valeur peut être supprimée lorsque le projet associé est définitivement supprimé. La suppression de cette valeur n'entraîne pas d'erreur. Vérifiez toujours si cette valeur existe lorsque vous essayez de résoudre des problèmes.

  • - resource: (soit cet attribut, soit l'attribut accessLevel doit être utilisé) : spécifie un projet ou un réseau VPC extérieur au périmètre auquel vous souhaitez accorder l'accès. Pour spécifier un projet, utilisez le format suivant : projects/PROJECT_NUMBER. Pour spécifier un réseau VPC, utilisez le format suivant : //compute.googleapis.com/projects/PROJECT_ID/global/networks/NETWORK_NAME.

  • - accessLevel: (soit cet attribut, soit l'attribut resource doit être utilisé) : indique le niveau d'accès extérieur au périmètre auquel l'accès est accordé. Si vous définissez l'attribut accessLevel sur "*", la règle d'entrée autorise l'accès depuis n'importe quelle origine du réseau.

  • ingressTo: (obligatoire) : ouvre le bloc to qui répertorie les opérations de service autorisées sur les ressources Google Cloud spécifiées du périmètre.

  • operations: (soit cet attribut, soit l'attribut roles doit être utilisé) : marque le début de la liste des services accessibles et des actions/méthodes auxquels un client qui remplit les conditions du bloc from est autorisé à accéder.

  • - serviceName: (obligatoire) : ce champ peut être un nom de service valide ou être défini sur "*" pour autoriser l'accès à tous les services. Par exemple, bigquery.googleapis.com est une valeur serviceName valide. Pour obtenir la liste des services disponibles, consultez la section Produits compatibles.

  • methodSelectors: (obligatoire si serviceName n'est pas "*") : marque le début d'une liste de méthodes auxquelles un client qui remplit les conditions du bloc from est autorisé à accéder. Pour obtenir la liste des méthodes et autorisations pouvant faire l'objet de restrictions pour les services, consultez la section Restrictions relatives aux méthodes de service compatibles.

    Pour obtenir la liste des méthodes de service que VPC Service Controls ne peut pas contrôler, consultez la section Exceptions concernant les méthodes de service.

  • - method: (soit cet attribut, soit l'attribut permission doit être utilisé) : ce champ peut être une méthode de service valide ou peut être défini sur "*" pour autoriser l'accès à toutes les méthodes du service spécifié.

  • - permission: (soit cet attribut, soit l'attribut method doit être utilisé) : ce champ doit être une autorisation de service valide. L'accès aux ressources du périmètre sera autorisé pour les opérations nécessitant cette autorisation.

    Lorsqu'une requête adressée à une ressource nécessite plusieurs autorisations, vous devez spécifier toutes les autorisations requises dans la même opération pour que la règle d'entrée fonctionne. Par exemple, si une requête adressée à une ressource BigQuery nécessite les autorisations bigquery.jobs.create et bigquery.tables.create, vous devez spécifier ces deux autorisations dans la même opération. De plus, si vous spécifiez plusieurs fois les autorisations pour la même ressource à l'aide de la consoleGoogle Cloud , les autorisations ne sont pas créées dans la même opération. Pour éviter ce problème, spécifiez toutes les autorisations à la fois pour la ressource.

  • roles: (soit cet attribut, soit l'attribut operations doit être utilisé) : cet attribut renvoie à une liste de rôles IAM qui définit le champ d'application de l'accès pour les services spécifiés dans la règle.

  • ROLE_NAME : spécifiez un seul rôle ou une combinaison de rôles incluant toutes les autorisations requises pour accéder aux services. Pour spécifier un rôle, utilisez les formats de nom de rôle mentionnés dans la section Composants des rôles, à l'exception du format suivant : projects/PROJECT_ID/roles/IDENTIFIER.

    Pour en savoir plus sur les services et les rôles compatibles, consultez la section Produits compatibles.

  • resources: (obligatoire) : cet attribut spécifie la liste des ressourcesGoogle Cloud du périmètre de service auxquelles le client extérieur au périmètre peut accéder. Ce champ peut être défini sur "*" pour autoriser l'accès entrant à n'importe quelle ressource Google Cloud située à l'intérieur du périmètre.

  • title: (facultatif) : cet attribut spécifie le titre de la règle d'entrée. Le titre doit être unique dans le périmètre et ne peut pas dépasser 100 caractères. Dans la stratégie d'accès, la longueur combinée de tous les titres de règles ne doit pas dépasser 240 000 caractères.

Pour créer une règle d'entrée fonctionnelle, vous devez spécifier les attributs suivants :

  • Attribut sources. Vous devez spécifier un attribut accessLevel ou resource (projetGoogle Cloud ou réseau VPC), ou définir l'attribut accessLevel sur "*".
  • Attribut identityType ou identities
  • Attribut resources
  • Attribut serviceName

Une fois que vous avez terminé de configurer votre fichier de règles d'entrée, consultez la section Mettre à jour les règles d'entrée et de sortie pour savoir comment appliquer votre fichier de règles d'entrée à votre périmètre de service.

Si vous configurez plusieurs règles d'entrée dans un périmètre de service, VPC Service Controls autorise une requête si elle remplit les conditions de l'une des règles d'entrée.

Documentation de référence sur les règles de sortie

Les règles de sortie peuvent être configurées à l'aide de la console Google Cloud , d'un fichier JSON ou d'un fichier YAML. L'exemple suivant utilise le format .yaml :

- egressTo:
    operations:
    - serviceName: SERVICE_NAME
      methodSelectors:
      - method: METHOD
      *OR*
      - permission: PERMISSION
    *OR*
    roles:
    - ROLE_NAME
    resources:
    - projects/PROJECT
    *OR*
    externalResources:
    - EXTERNAL_RESOURCE_PATH
  egressFrom:
    identityType: ANY_IDENTITY | ANY_USER_ACCOUNT | ANY_SERVICE_ACCOUNT
    *OR*
    identities:
    - PRINCIPAL_IDENTIFIER
    sources:
    - resource: RESOURCE
      *OR*
    - accessLevel: ACCESS_LEVEL
    sourceRestriction: RESTRICTION_STATUS
  title: TITLE
  • - egressTo: (obligatoire) : ouvre le bloc to qui répertorie les opérations de service autorisées sur les ressources Google Cloud dans les projets spécifiés extérieurs au périmètre.

  • operations: (soit cet attribut, soit l'attribut roles doit être utilisé) : marque le début de la liste des services accessibles et des actions/méthodes auxquels un client qui remplit les conditions du bloc from est autorisé à accéder.

  • - serviceName: (obligatoire) : ce champ peut être un nom de service valide ou être défini sur "*" pour autoriser l'accès à tous les services. Pour obtenir la liste des services disponibles, consultez la section Produits compatibles.

  • methodSelectors: (obligatoire si serviceName n'est pas "*") : marque le début d'une liste de méthodes auxquelles un client qui remplit les conditions du bloc from est autorisé à accéder. Pour obtenir la liste des méthodes et autorisations pouvant faire l'objet de restrictions pour les services, consultez la section Restrictions relatives aux méthodes de service compatibles.

    Pour obtenir la liste des méthodes de service que VPC Service Controls ne peut pas contrôler, consultez la section Exceptions concernant les méthodes de service.

  • - method: (soit cet attribut, soit l'attribut permission doit être utilisé) : ce champ peut être une méthode de service valide ou peut être défini sur "*" pour autoriser l'accès à toutes les méthodes du service spécifié.

  • - permission: (soit cet attribut, soit l'attribut method doit être utilisé) : ce champ doit être une autorisation de service valide. L'accès aux ressources spécifiées en dehors du périmètre sera autorisé pour les opérations nécessitant cette autorisation.

    Lorsqu'une requête adressée à une ressource nécessite plusieurs autorisations, vous devez spécifier toutes les autorisations requises dans la même opération pour que la règle de sortie fonctionne. Par exemple, si une requête adressée à une ressource BigQuery nécessite les autorisations bigquery.jobs.create et bigquery.tables.create, vous devez spécifier ces deux autorisations dans la même opération. De plus, si vous spécifiez plusieurs fois les autorisations pour la même ressource à l'aide de la consoleGoogle Cloud , les autorisations ne sont pas créées dans la même opération. Pour éviter ce problème, spécifiez toutes les autorisations à la fois pour la ressource.

  • roles: (soit cet attribut, soit l'attribut operations doit être utilisé) : cet attribut renvoie à une liste de rôles IAM qui définit le champ d'application de l'accès pour les services spécifiés dans la règle.

  • ROLE_NAME : spécifiez un seul rôle ou une combinaison de rôles incluant toutes les autorisations requises pour accéder aux services. Pour spécifier un rôle, utilisez les formats de nom de rôle mentionnés dans la section Composants des rôles, à l'exception du format suivant : projects/PROJECT_ID/roles/IDENTIFIER.

    Pour en savoir plus sur les services et les rôles compatibles, consultez la section Produits compatibles.

  • resources: : cet attribut est constitué d'une liste de ressources Google Cloudspécifiées par leurs projets auxquelles les clients situés dans un périmètre peuvent accéder. Vous pouvez définir ce champ sur "*" pour autoriser l'accès sortant à n'importe quelle ressourceGoogle Cloud .

  • externalResources: : cet attribut n'est utilisé que pour spécifier les ressources BigQuery Omni. Cet attribut est une liste des ressources externes compatibles avec BigQuery Omni auxquelles les clients situés dans un périmètre peuvent accéder. Vous ne pouvez spécifier que des ressources Amazon S3 ou Azure Blob Storage. Pour Amazon S3, le format accepté est s3://BUCKET_NAME. Pour Azure Storage, le format accepté est azure://myaccount.blob.core.windows.net/CONTAINER_NAME.

  • egressFrom: (obligatoire) : ouvre le bloc from qui répertorie les sources et identités autorisées dans le périmètre.

  • identityType: (soit cet attribut, soit l'attribut identities doit être utilisé) : cet attribut définit les types d'identités permettant d'accéder aux ressources spécifiées en dehors du périmètre. Valeurs acceptables : ANY_IDENTITY, ANY_USER_ACCOUNT, ANY_SERVICE_ACCOUNT. ANY_IDENTITY autorise les requêtes provenant de toutes les identités, y compris les requêtes non authentifiées. ANY_USER_ACCOUNT autorise tous les utilisateurs humains et ANY_SERVICE_ACCOUNT autorise tous les comptes de service, mais ni ANY_USER_ACCOUNT ni ANY_SERVICE_ACCOUNT n'autorisent les requêtes non authentifiées.

    Cet attribut ne limite pas les identités en fonction de l'organisation. Par exemple, ANY_SERVICE_ACCOUNT autorise un compte de service de n'importe quelle organisation.

  • identities: (soit cet attribut, soit l'attribut identityType doit être utilisé) : cet attribut ouvre une liste de comptes de service, de comptes utilisateur, de groupes Google ou d'identités tierces qui sont autorisés à accéder aux ressources spécifiées extérieures au périmètre.

  • PRINCIPAL_IDENTIFIER : spécifiez un compte utilisateur, un compte de service, un groupe Google ou une identité tierce pouvant accéder aux ressources spécifiées extérieures au périmètre. VPC Service Controls n'accepte que les identités suivantes à partir des identifiants de compte principal de l'API IAM v1 :

    • Pour les comptes utilisateur et les comptes de service, utilisez respectivement les formats user:USER_EMAIL_ADDRESS et serviceAccount:SA_EMAIL_ADDRESS.

    • Pour les autres identités, utilisez les formats spécifiés dans la section Groupes d'identités compatibles.

    Pour en savoir plus sur ces identités, consultez Identifiants de compte principal pour les règles d'autorisation.

  • sources: : cet attribut spécifie une liste d'origines de réseau. La valeur de l'attribut peut être une liste de projets ou de niveaux d'accès. Pour appliquer des restrictions d'accès en fonction des sources spécifiées, définissez l'attribut sourceRestriction sur SOURCE_RESTRICTION_ENABLED.

    VPC Service Controls évalue les attributs accessLevel et resource de l'attribut sources en tant que condition OR.

  • - resource: (soit cet attribut, soit l'attribut accessLevel doit être utilisé) : cet attribut spécifie une ou plusieurs ressourcesGoogle Cloud du périmètre de service auxquelles vous souhaitez autoriser l'accès aux données extérieures au périmètre. Cet attribut n'accepte que les projets. Pour spécifier un projet, utilisez le format suivant : projects/PROJECT_NUMBER.

    Vous ne pouvez pas utiliser "*" dans cet attribut pour autoriser toutes les ressources Google Cloud .

  • - accessLevel: (soit cet attribut, soit l'attribut resource doit être utilisé) : cet attribut spécifie un ou plusieurs niveaux d'accès qui permettent aux ressources situées dans le périmètre d'accéder aux ressources extérieures à ce périmètre. Assurez-vous que ces niveaux d'accès proviennent de la même règle d'accès que le périmètre. Si vous définissez l'attribut accessLevel sur "*", la règle de sortie autorise l'accès depuis n'importe quelle origine du réseau.

  • sourceRestriction: (obligatoire si vous utilisez l'attribut sources) : cet attribut vous permet d'appliquer des restrictions d'accès en fonction de l'attribut sources spécifié. Pour appliquer ces restrictions d'accès, définissez l'attribut sourceRestriction sur SOURCE_RESTRICTION_ENABLED.

    Pour désactiver ces restrictions d'accès, définissez l'attribut sourceRestriction sur SOURCE_RESTRICTION_DISABLED.

    Si vous ne définissez aucune valeur pour l'attribut sourceRestriction, VPC Service Controls ignore l'attribut sources et n'applique aucune restriction d'accès.

  • title: (facultatif) : cet attribut spécifie le titre de la règle de sortie. Le titre doit être unique dans le périmètre et ne peut pas dépasser 100 caractères. Dans la stratégie d'accès, la longueur combinée de tous les titres de règles ne doit pas dépasser 240 000 caractères.

Une fois que vous avez terminé de configurer votre fichier de règles de sortie, consultez la section Mettre à jour les règles d'entrée et de sortie pour savoir comment appliquer votre fichier de règles de sortie à votre périmètre de service.

Si vous configurez plusieurs règles de sortie dans un périmètre de service, VPC Service Controls autorise une requête si elle remplit les conditions de l'une des règles de sortie.

Tester le fonctionnement des règles d'entrée et de sortie à l'aide du mode dry run

Si vous ne souhaitez pas accorder l'accès à toutes les méthodes d'un service, il peut parfois être difficile de déterminer la liste exacte des méthodes à autoriser. Ce cas de figure peut se produire, car une méthode donnée pour un service peut entraîner l'appel d'une autre méthode sur un service Google Cloud distinct. Par exemple, BigQuery charge une table à partir d'un bucket Cloud Storage pour exécuter une requête.

Pour déterminer l'ensemble exact des méthodes à autoriser, vous pouvez utiliser le mode dry run de VPC Service Controls. Pour ce faire, vous devez commencer par activer un périmètre en mode dry run sans aucune règle d'entrée ou de sortie, puis collecter la liste des méthodes appelées à partir du journal d'audit. Ensuite, toujours en mode dry run, ajoutez progressivement ces méthodes aux règles d'entrée et de sortie jusqu'à l'arrêt des cas de non-respect. À ce stade, la configuration peut être transférée du mode dry run vers le mode forcé.

Fonctionnalités non compatibles

Les fonctionnalités suivantes ne sont actuellement pas compatibles avec les règles d'entrée et de sortie :

  1. Identification des ressources Google Cloud à l'aide de libellés plutôt que par projet.
  2. Certains services ne sont pas compatibles avec les règles d'entrée ou de sortie par méthode. Consultez la section Restrictions relatives aux méthodes de service compatibles.
  3. Les types d'identité ANY_SERVICE_ACCOUNT et ANY_USER_ACCOUNT ne peuvent pas être utilisés pour autoriser les opérations suivantes :
  4. Prenez connaissance des limites d'utilisation des groupes d'identité dans les règles d'entrée et de sortie.

Limites

Pour plus d'informations sur les limites des règles d'entrée et de sortie, consultez la page Quotas et limites.

Étapes suivantes