Autoriser l'accès aux ressources protégées depuis une adresse IP interne

Cette page explique comment autoriser le trafic provenant d'adresses IP internes d'un réseau VPC vers des périmètres de service à l'aide de règles d'entrée et de sortie.

Présentation

Vous pouvez utiliser VPC Service Controls pour spécifier des conditions permettant à des plages d'adresses IP spécifiques du réseau VPC d'accéder aux projets et aux réseaux VPC protégés. Cette fonctionnalité vous permet d'effectuer les tâches suivantes:

  • Prise en charge des conditions de niveau d'accès de base pour autoriser les plages d'adresses IP internes des réseaux VPC.

  • Autorisez l'utilisation de ces conditions de niveau d'accès pour les appels d'API entrants ou sortants dans ou hors de la limite du périmètre de service.

Cette fonctionnalité offre les avantages suivants:

  • Vous pouvez spécifier des conditions dans les configurations VPC Service Controls pour autoriser l'accès à partir d'une adresse IP interne dans un réseau VPC.

  • Les workflows qui nécessitent que les appels d'API passent par plusieurs périmètres de service peuvent limiter l'accès à quelques sous-réseaux au lieu de permettre l'accès à l'ensemble du réseau ou du projet VPC.

  • Vous pouvez configurer différentes ressources sur site pour n'accéder qu'à des ressources Google Cloud spécifiques. Vous devez utiliser la plage d'adresses IP du sous-réseau associée à ces ressources sur site et au réseau VPC de la zone de destination dans le cadre du niveau d'accès.

La figure 1 présente un exemple de configuration qui permet d'accéder à un service protégé spécifique à partir d'une adresse IP interne autorisée.

Limites de l'utilisation d'une adresse IP interne

Lorsque vous utilisez une adresse IP interne dans VPC Service Controls, les limites suivantes s'appliquent:

  • Vous ne pouvez activer une adresse IP interne qu'avec des niveaux d'accès de base et non avec des niveaux d'accès personnalisés.

  • Nous vous recommandons de ne pas inverser les niveaux d'accès avec des conditions basées sur les adresses IP internes, car cela peut entraîner des comportements inattendus.

  • Les limites liées à l'ajout de réseaux VPC aux périmètres de service s'appliquent également.

  • Lorsque VPC Service Controls enregistre un journal d'audit de refus de règle, il remplace le nom du réseau VPC par __UNKNOWN__ dans le journal d'audit.

  • Les réseaux VPC pour lesquels SUBNET_MODE est défini sur custom, mais qui ne disposent pas de sous-réseaux, ne sont pas compatibles. Pour activer les adresses IP internes, un réseau VPC doit contenir au moins un sous-réseau.

  • Vous ne pouvez spécifier que 500 réseaux VPC pour tous les niveaux d'accès de votre règle d'accès.

  • Lorsque vous supprimez un réseau VPC référencé par un niveau d'accès ou un périmètre de service, puis que vous recréez un autre réseau VPC avec le même nom, VPC Service Controls n'active pas automatiquement les adresses IP internes sur le réseau VPC recréé. Pour contourner cette limitation, créez un réseau VPC avec un nom différent et ajoutez-le au périmètre.

  • Vous ne pouvez pas utiliser une adresse IP interne pour autoriser l'accès à partir de services gérés par Google. (par exemple, Cloud SQL).

  • Si vous utilisez un niveau d'accès qui comporte des conditions basées sur des adresses IP internes avec une règle de sortie, nous vous recommandons de ne pas ajouter d'autres conditions telles que le type d'appareil ou l'identité de l'utilisateur au niveau d'accès.

  • L'adresse IP interne ne correspond pas aux niveaux d'accès faisant référence à des régions géographiques.

Utiliser une adresse IP interne dans les niveaux d'accès

  1. Spécifiez le nom du réseau VPC et la plage d'adresses IP dans le champ vpcNetworkSources de la condition de niveau d'accès de base.

    • Nom du réseau VPC Vous devez définir le nom de réseau du VPC au format suivant:

      //compute.googleapis.com/projects/PROJECT_ID/global/networks/NETWORK_NAME

      Par exemple, //compute.googleapis.com/projects/my-project/global/networks/my-vpc.

    • Plage d'adresses IP. La plage d'adresses IP spécifiée dans le champ VpcSubNetwork de VpcNetworkSource doit respecter les spécifications du sous-réseau IP du bloc CIDR. Vous pouvez utiliser n'importe quelle plage d'adresses IP qui est une plage IPv4 valide pour les sous-réseaux.

  2. Utilisez ce niveau d'accès avec des conditions d'autorisation dans IngressSource ou EgressSource.

Les sections suivantes expliquent comment effectuer ces étapes pour activer une adresse IP interne à l'aide d'un exemple de scénario.

Exemple d'utilisation d'une adresse IP interne pour configurer l'accès au sous-réseau

Dans l'exemple suivant, vous avez deux projets:

  1. Projet hôte réseau:Project1 héberge un réseau VPC : default. Les deux VM de Project1, VM1 et VM2, utilisent ce réseau comme interface réseau pour envoyer du trafic.

  2. Projet Cloud Storage:Project2 contient un bucket Cloud Storage.

Vous pouvez utiliser VPC Service Controls pour n'autoriser que VM1 à partir de Project1 à accéder au bucket Cloud Storage dans Project2 à l'aide d'une adresse IP interne. Pour ce faire, procédez comme suit:

  1. Vous créez un périmètre de service sp1 autour de Project1 et un autre périmètre de service sp2 autour de Project2.

  2. Vous pouvez ensuite ajouter des règles d'entrée et de sortie aux périmètres de service pour n'autoriser que le sous-réseau de VM1 à accéder au bucket Cloud Storage.

Le schéma suivant illustre la configuration décrite dans cet exemple.

Configurer une stratégie d'accès au niveau de l'organisation

  1. Assurez-vous de disposer d'une stratégie d'accès au niveau de l'organisation. Si vous ne disposez pas d'une stratégie d'accès à ce niveau, exécutez la commande gcloud CLI suivante:

    gcloud access-context-manager policies create \
    --organization=ORGANIZATION_ID --title=POLICY_TITLE

    Remplacez les éléments suivants :

    • ORGANIZATION_ID: ID numérique de votre organisation.

    • POLICY_TITLE: titre lisible de votre stratégie d'accès.

    Pour en savoir plus, consultez Créer une règle d'accès au niveau de l'organisation.

  2. Obtenez le nom de votre règle d'accès.

  3. Pour définir cette règle comme règle d'accès par défaut, exécutez la commande gcloud CLI suivante:

    gcloud config set access_context_manager/policy POLICY_NAME

    Remplacez POLICY_NAME par le nom numérique de votre règle d'accès.

    Pour en savoir plus, consultez Définir la stratégie d'accès par défaut de l'outil de ligne de commande gcloud.

Créer des périmètres pour protéger le projet hôte réseau et le projet Cloud Storage

  1. Pour créer un périmètre sp1 autour de Project1, exécutez la commande gcloud CLI suivante:

    gcloud access-context-manager perimeters create sp1 --title="sp1" --resources=PROJECT_NUMBER \
    --restricted-services=storage.googleapis.com --policy=POLICY_NAME

    Remplacez les éléments suivants :

    • PROJECT_NUMBER: numéro du projet hôte de réseau. Exemple :projects/111

    • POLICY_NAME: nom numérique de votre règle d'accès. Exemple : 1234567890.

  2. Pour créer un périmètre sp2 autour de Project2 qui limite le service Cloud Storage, exécutez la commande gcloud CLI suivante:

    gcloud access-context-manager perimeters create sp2 --title="sp2" --resources=PROJECT_NUMBER \
    --restricted-services=storage.googleapis.com --policy=POLICY_NAME

    Remplacez les éléments suivants :

    • PROJECT_NUMBER: numéro de projet du projet Cloud Storage. Exemple :projects/222

    • POLICY_NAME: nom numérique de votre règle d'accès. Exemple : 1234567890.

Pour en savoir plus sur la création d'un périmètre de service, consultez la section Créer un périmètre de service.

Une fois ces deux périmètres créés, le bucket Cloud Storage n'est plus accessible depuis les deux VM.

Créer un niveau d'accès avec une condition d'accès basée sur une adresse IP interne

Créez un niveau d'accès qui n'autorise que le trafic provenant du sous-réseau de VM1.

  1. Créez un fichier YAML qui définit vos conditions d'accès. L'exemple suivant n'affiche que les attributs dont vous avez besoin pour activer une adresse IP interne:

    echo """
- vpcNetworkSources:
  - vpcSubnetwork:
      network: VPC_NETWORK_NAME
      vpcIpSubnetworks:
      - IP_RANGE

""" > level.yaml

    Remplacez les éléments suivants :

    • VPC_NETWORK_NAME: nom du réseau VPC où se trouve le VM1. Exemple : //compute.googleapis.com/projects/Project1/global/networks/default.

    • IP_RANGE: plage d'adresses IP du sous-réseau. Exemple : 10.10.0.0/24.

    Utilisez le nom du réseau VPC et les formats de plage d'adresses IP expliqués précédemment.

    Pour en savoir plus sur le fichier YAML, consultez le fichier YAML basic-level-spec.

  2. Pour créer un niveau d'accès à l'aide du fichier YAML, exécutez la commande gcloud CLI suivante:

    gcloud access-context-manager levels create LEVEL_NAME \
    --title="TITLE" --basic-level-spec=FILE_NAME

    Remplacez les éléments suivants :

    • LEVEL_NAME: nom unique du niveau d'accès. Exemple : allowvm1.

    • TITLE: titre court et lisible du niveau d'accès. Exemple :allowvm1

    • FILE_NAME: fichier YAML qui définit vos conditions d'accès pour le niveau d'accès. Exemple :level.yaml

    Pour en savoir plus, consultez Créer un niveau d'accès de base.

Configurer une stratégie d'entrée pour autoriser le trafic API entrant vers le bucket Cloud Storage

Pour n'autoriser l'accès qu'à partir de VM1, configurez une stratégie d'entrée dans le périmètre sp2 pour autoriser le trafic de l'API Cloud Storage à pénétrer dans le périmètre.

  1. Créez un fichier YAML qui définit votre règle d'entrée.

    echo """
- ingressFrom:
    identityType: ANY_IDENTITY
    sources:
    - accessLevel: accessPolicies/POLICY_NAME/accessLevels/ACCESS_LEVEL_NAME
  ingressTo:
    operations:
    - methodSelectors:
      - method: '*'
      serviceName: storage.googleapis.com
    resources:
    - '*'

""" > ingress.yaml

    Remplacez les éléments suivants :

    • POLICY_NAME: nom numérique de votre règle d'accès. Exemple : 1234567890.

    • ACCESS_LEVEL_NAME: nom de votre niveau d'accès. Exemple : allowvm1.

    Pour en savoir plus sur le fichier YAML, consultez la documentation de référence sur les règles d'entrée.

  2. Pour mettre à jour la stratégie d'entrée d'un périmètre de service, exécutez la commande gcloud CLI suivante:

    gcloud access-context-manager perimeters update PERIMETER --set-ingress-policies=FILE_NAME

    Remplacez les éléments suivants :

    • PERIMETER: nom du périmètre de service qui protège le projet Cloud Storage. Exemple :sp2

    • FILE_NAME: fichier YAML qui définit votre stratégie d'entrée. Exemple : ingress.yaml.

    Pour en savoir plus, consultez la section Mettre à jour les règles d'entrée et de sortie pour un périmètre de service.

Configurer une stratégie de sortie pour autoriser le trafic sortant de l'API vers le bucket Cloud Storage

En outre, configurez une règle de sortie dans le périmètre sp1 pour autoriser le trafic de l'API Cloud Storage à quitter le périmètre.

  1. Créez un fichier YAML qui définit votre règle de sortie. Assurez-vous de définir le champ sourceRestriction sur SOURCE_RESTRICTION_ENABLED dans le fichier YAML.

    echo """
- egressFrom:
    identityType: ANY_IDENTITY
    sourceRestriction: SOURCE_RESTRICTION_ENABLED
    sources:
    - accessLevel: accessPolicies/POLICY_NAME/accessLevels/ACCESS_LEVEL_NAME
  egressTo:
    operations:
    - methodSelectors:
      - method: '*'
      serviceName: storage.googleapis.com
    resources:
    - '*'

""" > egress.yaml

    Remplacez les éléments suivants :

    • POLICY_NAME: nom numérique de votre règle d'accès. Exemple : 1234567890.

    • ACCESS_LEVEL_NAME: nom de votre niveau d'accès. Exemple : allowvm1.

    Pour en savoir plus sur le fichier YAML, consultez la documentation de référence sur les règles de sortie.

  2. Pour mettre à jour la règle de sortie d'un périmètre de service, exécutez la commande suivante:

    gcloud access-context-manager perimeters update PERIMETER --set-egress-policies=FILE_NAME

    Remplacez les éléments suivants :

    • PERIMETER: nom de votre périmètre de service qui protège le projet hôte réseau. Exemple :sp1

    • FILE_NAME: fichier YAML qui définit votre stratégie de sortie. Exemple : egress.yaml.

    Pour en savoir plus, consultez la section Mettre à jour les règles d'entrée et de sortie pour un périmètre de service.

Une fois que vous avez configuré les règles d'entrée et de sortie, le bucket Cloud Storage est accessible depuis VM1, mais pas depuis VM2.

Recommandations

  • Lorsque vous activez une adresse IP interne, nous vous recommandons de désactiver le transfert d'adresses IP pour vos VM. Le transfert d'adresses IP permet à une VM du même réseau VPC d'envoyer des requêtes à l'aide d'une autre adresse IP, ce qui présente le risque d'une usurpation d'adresse IP.

  • Si vous souhaitez activer le transfert d'adresses IP, nous vous recommandons d'utiliser les configurations suivantes pour réduire le risque d'usurpation d'adresse IP:

    • Utilisez la contrainte de règle d'administration (constraints/compute.vmCanIpForward) Restrict VM IP Forwarding pour vous assurer que seules les VM autorisées peuvent activer le transfert IP.

    • Utilisez des sources pour les règles de pare-feu pour limiter les adresses IP pouvant communiquer avec les VM pour lesquelles le transfert IP est activé. Effectuez les tâches suivantes :

      • Configurez des règles de pare-feu d'entrée pour n'autoriser le trafic entrant que depuis une plage d'adresses IP spécifique vers les VM pour lesquelles le transfert IP est activé.

      • Configurez des règles de pare-feu de sortie pour n'autoriser le trafic sortant que vers une plage d'adresses IP spécifique à partir des VM pour lesquelles le transfert IP est activé.