En savoir plus sur l'utilisation des adresses IP privées

Cette page fournit des informations sur l'utilisation de la connectivité IP privée avec Cloud SQL. Pour obtenir des instructions détaillées sur la configuration d'une instance Cloud SQL en vue de l'utilisation d'une adresse IP privée, consultez la page Configurer une adresse IP privée.

Présentation

La configuration d'une instance Cloud SQL pour qu'elle utilise une adresse IP privée nécessite un accès privé aux services. L'accès privé aux services vous permet de créer des connexions privées entre votre réseau VPC et le réseau VPC du producteur de services Google sous-jacent. Les entités Google qui offrent des services, tels que Cloud SQL, sont appelées producteurs de services. Chaque service Google crée un sous-réseau dans lequel le client peut provisionner des ressources. La plage d'adresses IP du sous-réseau est généralement un bloc CIDR de /24 choisi par le service et provenant de la plage d'adresses IP allouée.

Les connexions privées permettent d'accéder aux services sans passer par Internet ni utiliser d'adresses IP externes. Pour cette raison, l'adresse IP privée fournit une latence réseau inférieure à celle des adresses IP publiques.

L'accès privé aux services vous permet de vous connecter à des instances Cloud SQL :

Vous pouvez vous connecter via une adresse IP privée entre différentes régions. Vous pouvez également vous connecter par le biais d'un VPC partagé entre des projets.

Plages d'adresses IP allouées

Pour utiliser des instances Cloud SQL dans un réseau VPC avec une adresse IP privée, vous devez allouer des plages d'adresses IP afin de configurer l'accès privé aux services pour ce VPC. Pour organiser vos instances Cloud SQL, vous pouvez allouer plusieurs plages d'adresses IP pour la connexion privée. Lorsque vous configurez une instance Cloud SQL pour une adresse IP privée, vous pouvez sélectionner le réseau VPC et la plage d'adresses IP allouée.

Taille de la plage allouée

Veuillez allouer des plages d'adresses IP suffisamment grandes pour Cloud SQL et les autres services gérés par Google que vous prévoyez d'utiliser. Chacun d'entre eux nécessiterait des blocs d'adresses IP dédiés des plages allouées. La taille minimale est un bloc unique de /24 (256 adresses), mais la taille recommandée est un bloc de /16 (65 536 adresses).

Lorsque vous allouez une plage d'adresses IP, vous devez prendre en compte le nombre d'instances que vous prévoyez de créer.

Masque de sous-réseau Adresses Instances Cloud SQL utilisables
/2425650
/23512100
/221 024200
/212 048400
/204 096800

Cloud SQL utilise des plages CIDR /24 comme unité de plage, et chaque unité ne peut être utilisée que pour les instances Cloud SQL d'une seule région. Ainsi, même si seulement deux instances Cloud SQL doivent être créées, mais dans des régions différentes, vous devez disposer d'au moins 2 plages CIDR /24.

En outre, si un projet a commencé à utiliser Cloud SQL avant le 1er avril 2021, les instances Postgres ne peuvent pas partager la même unité de plage avec des instances MySQL et SQL Server, et ont besoin de leurs propres instances dans chaque région. Les projets plus récents ne sont pas soumis à cette limitation.

Configurer l'accès aux services privés pour votre réseau

Lorsque vous configurez la connectivité IP privée pour la première fois sur un réseau VPC donné, vous devez effectuer une procédure ponctuelle afin de mettre en place l'accès aux services privés pour Cloud SQL.

Une fois que vous avez établi l'accès aux services privés, vous pouvez créer une instance Cloud SQL configurée pour utiliser une adresse IP privée, ou bien configurer une adresse IP privée pour une instance Cloud SQL existante. Pour obtenir des instructions détaillées, consultez la page Configurer une adresse IP privée.

Chaque fois que vous modifiez une connexion établie, vous devez également mettre à jour vpc-peerings.

Configuration requise pour les adresses IP privées

Pour utiliser des adresses IP privées, votre réseau et votre environnement d’application doivent répondre aux exigences décrites ci-après. En outre, la configuration initiale d'adresses IP privées nécessite certaines autorisations IAM spécifiques.

Exigences relatives à l'environnement d'application

  • Si vous vous connectez depuis GKE, vous devez en exécuter la version 1.8 ou une version ultérieure sur un cluster de VPC natif.

Exigences relatives à l'API et à IAM

  • Vous devez activer l'API Service Networking pour votre projet.
  • Si vous utilisez un réseau VPC partagé, vous devez également activer l'API Service Networking pour le projet hôte.

  • Pour gérer une connexion d'accès aux services privés, votre utilisateur doit disposer des autorisations IAM suivantes. Si l'utilisateur ne dispose pas des autorisations requises, vous pouvez obtenir des erreurs d'autorisations insuffisantes.
    • compute.networks.list
    • compute.addresses.create
    • compute.addresses.list
    • servicenetworking.services.addPeering

    Si vous utilisez un réseau VPC partagé, vous devez également ajouter le même utilisateur et attribuer les mêmes autorisations sur le projet hôte.

Exemple

Dans l'exemple suivant, le réseau VPC du client a alloué la plage d'adresses 10.240.0.0/16 aux services Google et a établi une connexion privée utilisant cette plage. Chaque service Google (par exemple, Cloud SQL) crée un sous-réseau à partir du bloc alloué pour provisionner de nouvelles ressources dans une région donnée, telles que des instances Cloud SQL.

Diagramme de configuration d'adresses IP privées

  • La connexion privée se voit attribuer la plage 10.240.0.0/16. À partir de cette allocation, les services Google peuvent créer des sous-réseaux où de nouvelles ressources sont provisionnées.
  • Du côté des services Google de la connexion privée, Google crée un projet pour le client. Le projet est isolé, ce qui signifie qu'il n'est partagé avec aucun autre client, et le client est facturé à hauteur des seules ressources qu'il fournit.
  • Chaque service Google crée un sous-réseau dans lequel le client peut provisionner des ressources. La plage d'adresses IP du sous-réseau est généralement un bloc CIDR de /24 choisi par le service et provenant de la plage d'adresses IP allouée. Vous ne pouvez pas modifier le sous-réseau du producteur de services. Un service provisionne de nouvelles ressources dans les sous-réseaux régionaux existants précédemment créés par ce service. Si un sous-réseau est saturé, le service crée un nouveau sous-réseau dans la même région.
  • Les instances de VM du réseau du client peuvent accéder aux ressources de service de n'importe quelle région si le service est compatible. Cependant, certains services peuvent ne pas être compatibles avec la communication interrégionale. Consultez la documentation du service concerné pour plus d'informations.
  • Les coûts de sortie applicables au trafic interrégional, dans lequel une instance de VM communique avec des ressources situées dans une région différente, continuent de s'appliquer.
  • L'instance Cloud SQL se voit attribuer l'adresse IP 10.240.0.2. Dans le réseau VPC du client, les requêtes dont la destination est 10.240.0.2 sont acheminées vers la connexion privée via le réseau du producteur de services. Lorsque les requêtes ont atteint le réseau de service, celui-ci contient des routes qui les dirigent vers la ressource appropriée.
  • Le trafic entre les réseaux VPC circule en interne au sein du réseau de Google et non via l'Internet public.

Problèmes de réseau

Cloud SQL alloue un sous-réseau de taille /24 appartenant à la plage d'adresses IP d'accès aux services privés pour chaque région. Par exemple, pour placer des instances SQL Server dans deux régions, la plage d'adresses IP allouée doit contenir au moins deux sous-réseaux de taille /24.

Les connexions à une instance Cloud SQL à l'aide d'une adresse IP privée sont automatiquement autorisées pour les plages d'adresses RFC 1918. De cette manière, tous les clients privés peuvent accéder à la base de données sans passer par le proxy d'authentification Cloud SQL. Les plages d'adresses non-RFC 1918 doivent être configurées en tant que réseaux autorisés.

Par défaut, Cloud SQL n'apprend pas les routes de sous-réseau non-RFC 1918 à partir de votre VPC. Vous devez mettre à jour l'appairage de réseaux vers Cloud SQL pour exporter les routes non-RFC 1918.

Sécurité

Un certain niveau de chiffrement est fourni pour le trafic circulant via l'accès aux services privés. Pour en savoir plus, consultez la page Chiffrement et authentification du réseau virtuel de Google Cloud.

Vous pouvez configurer le proxy d'authentification Cloud SQL pour qu'il se connecte via une adresse IP privée et fournisse une authentification à l'aide d'identifiants IAM, ainsi qu'un chiffrement de bout en bout utilisant un certificat SSL/TLS en rotation.

Si vous gérez vous-même vos certificats SSL/TLS afin de répondre à des exigences de sécurité spécifiques, consultez les instructions fournies sur la page Configurer SSL/TLS.

La création d'un réseau VPC pour chaque instance avec une adresse IP privée offre une meilleure isolation du réseau plutôt que de placer toutes les instances dans le réseau VPC "par défaut".

Aide-mémoire des rubriques concernant les adresses IP privées

Si vous gérez des instances Cloud SQL utilisant des adresses IP privées, certaines des thématiques suivantes peuvent vous intéresser :

Sujet Discussion
Réseaux VPC partagés Vous pouvez créer des instances Cloud SQL dotées d'adresses IP privées dans un réseau VPC partagé. Cependant, vous ne pouvez pas attribuer à une instance Cloud SQL existante une adresse IP privée dans un réseau VPC partagé.
Régions Vous pouvez vous connecter via une adresse IP privée entre différentes régions.
Anciens réseaux Vous ne pouvez pas vous connecter à l'adresse IP privée d'une instance Cloud SQL depuis un ancien réseau. Les anciens réseaux ne sont pas compatibles avec l’appairage de réseaux VPC ni avec l’accès privé aux services.
Suppression d'une adresse IP privée Une fois que vous avez configuré une instance Cloud SQL pour qu'elle utilise une adresse IP privée, vous ne pouvez pas retirer la fonctionnalité d'adresse IP privée de cette instance.
Adresses IP publique et privée Vous pouvez utiliser à la fois une adresse IP publique et une adresse IP privée pour vous connecter à la même instance Cloud SQL. Ces deux méthodes de connexion ne sont pas incompatibles.
Instances Cloud SQL existantes Vous pouvez configurer une instance pour qu'elle utilise une adresse IP privée au moment de sa création. Vous pouvez également configurer une instance existante de sorte qu'elle utilise une adresse IP privée. Lorsque vous configurez une instance existante pour qu'elle utilise une adresse IP privée ou que vous modifiez le réseau auquel elle est connectée, l'instance redémarre, ce qui entraîne un temps d'arrêt de quelques minutes.
Adresses IP statiques L'adresse IP privée de l'instance Cloud SQL est statique. Elle ne change pas.
Instances dupliquées Les instances dupliquées héritent du même état de connectivité IP privée que l'instance principale. Vous ne pouvez pas configurer une adresse IP privée directement sur une instance dupliquée. Si vous vous connectez à une instance dupliquée à l'aide d'une adresse IP privée, vous n'avez pas besoin de créer une connexion VPC privée supplémentaire pour l'instance dupliquée, car elle est héritée de l'instance principale.
Le proxy d'authentification Cloud SQL Pour permettre la connexion à une instance Cloud SQL à l'aide d'une adresse IP privée, le proxy d'authentification Cloud SQL doit se trouver sur une ressource ayant accès au même réseau VPC que l'instance. Si les deux types d'adresses IP sont activés sur l'instance, le proxy d'authentification Cloud SQL utilise par défaut l'adresse IP publique. Pour vous assurer qu'elle utilise une adresse IP privée, vous devez transmettre l'option -ip_address_types=PRIVATE au proxy d'authentification Cloud SQL. En savoir plus
Accès au VPC sans serveur Pour vous connecter à partir d'une source sans serveur, telle que l'environnement standard App Engine, Cloud Run ou Cloud Functions, votre application ou fonction se connecte directement à votre instance via l'accès au VPC sans serveur, sans proxy d'authentification Cloud SQL.
Appairage de réseaux VPC Une connexion utilisant l'accès privé aux services repose sur l'appairage de réseaux VPC. Cependant, vous ne créez pas explicitement l'appairage de réseaux VPC, car celui-ci est interne à Google Cloud. Après avoir créé la connexion d'accès aux services privés, vous pouvez voir son appairage au réseau VPC sous-jacent sur la page Appairage de réseaux VPC de Cloud Console. Ne supprimez pas cet appairage, sauf si vous souhaitez supprimer la connexion privée.

Apprenez-en plus sur l'appairage de réseaux VPC.

VPC Service Controls VPC Service Controls améliore votre capacité à limiter le risque d'exfiltration des données. Cette solution vous permet de créer des périmètres autour de l'instance Cloud SQL. VPC Service Controls limite l'accès depuis l'extérieur aux ressources situées dans le périmètre. Seuls les clients et les ressources situés dans le périmètre peuvent interagir entre eux. Pour en savoir plus, consultez la page Présentation de VPC Service Controls. Consultez également les limites applicables à Cloud SQL lors de l'utilisation de VPC Service Controls. Pour utiliser VPC Service Controls avec Cloud SQL, consultez la page Configurer VPC Service Controls.
Appairage transitif Seuls les réseaux directement appairés peuvent communiquer. L'appairage transitif n'est pas compatible. En d'autres termes, si le réseau VPC N1 est appairé à N2 et N3, mais que N2 et N3 ne sont pas directement connectés, le réseau VPC N2 ne peut pas communiquer avec le réseau VPC N3 via l'appairage de réseaux VPC.

Les clients d'un projet donné peuvent se connecter aux instances Cloud SQL dans d'autres projets à l'aide des réseaux VPC partagés.

Déplacement d'instances Cloud SQL Les instances Cloud SQL ne peuvent être déplacées qu'entre des réseaux appartenant au projet dans lequel elles résident. Par ailleurs, il n'est pas possible de déplacer des instances Cloud SQL d'un projet à l'autre, ni entre des réseaux hébergés par des projets différents.

Étape suivante