Accéder en privé aux services sur des réseaux superposés dans Google Cloud

gcloud compute instance-templates create nginx-service-instance-template \
--machine-type=e2-medium \
--network-interface=network=default,no-address \
--metadata=startup-script=\ \#\!\ /bin/bash


Créez un managed instance group dans le projet B.

gcloud beta compute instance-groups managed create nginx-service-instance-group \
--base-instance-name=nginx-service \
--size=1 \
--template=nginx-service-instance-template \
--zone=us-west4-a \
--list-managed-instances-results=PAGELESS \
--no-force-update-on-repair \
--project=$PROJECT_B
Une fois la création réussie, le managed instance group lance une instance dans la zone cible.
Connectez-vous en SSH à l'instance et vérifiez l'état du service nginx.




Créez une instance de test de connectivité dans le projet A.

gcloud compute instances create instance-1 \
    --zone=us-west4-b \
    --machine-type=e2-medium \
    --network-interface=stack-type=IPV4_ONLY,subnet=default,no-address \
    --maintenance-policy=MIGRATE \
    --provisioning-model=STANDARD \
    --scopes=https://www.googleapis.com/auth/cloud-platform \
    --create-disk=auto-delete=yes,boot=yes,device-name=instance-2,image=projects/centos-cloud/global/images/centos-7-v20230411,mode=rw,size=20,type=projects/project-a-385206/zones/us-west4-b/diskTypes/pd-balanced \
    --no-shielded-secure-boot \
    --shielded-vtpm \
    --shielded-integrity-monitoring \
    --labels=ec-src=vm_add-gcloud \
    --reservation-affinity=any \
    --project=$PROJECT_A

Les réseaux des projets A et B n'ont aucune connectivité interne. L'instance du projet A ne peut donc pas accéder au service exécuté dans le projet B.
Le VPC peering est impossible en raison du chevauchement des plages dans le réseau par défaut.
Mettre en place le load balancer interne
Un load balancer interne est nécessaire pour que Private Service Connect expose le service via un service attachment. Nous allons créer un load balancer TCP interne dans le projet B pour cette configuration.

Créez un nouveau health check HTTP régional pour tester la connectivité HTTP aux VM sur le port 80.

gcloud compute health-checks create http nginx-service-health-check \
    --region=us-west4 \
    --port=80 \
    --project=$PROJECT_B

Créez le service backend pour le trafic HTTP.

gcloud compute backend-services create nginx-service-internal-lb-backend \
    --load-balancing-scheme=internal \
    --protocol=tcp \
    --region=us-west4 \
    --health-checks=nginx-service-health-check \
    --health-checks-region=us-west4 \
    --project=$PROJECT_B

Ajoutez l'instance group du service nginx au service backend.

gcloud compute backend-services add-backend nginx-service-internal-lb-backend \
    --region=us-west4 \
    --instance-group=nginx-service-instance-group \
    --instance-group-zone=us-west4-a \
    --project=$PROJECT_B

Créez une forwarding rule pour le service backend.

gcloud compute forwarding-rules create nginx-service-internal-fr \
    --region=us-west4 \
    --load-balancing-scheme=internal \
    --network=default \
    --subnet=default \
    --ip-protocol=TCP \
    --ports=80 \
    --backend-service=nginx-service-internal-lb-backend \
    --backend-service-region=us-west4 \
    --project=$PROJECT_B

Configurez une règle de pare-feu pour autoriser les health checks du load balancer.

gcloud compute firewall-rules create allow-internal-lb-health-check \
--direction=INGRESS \
--priority=1000 \
--network=default \
--action=ALLOW \
--rules=tcp:80 \
--source-ranges=35.191.0.0/16,130.211.0.0/22
--project=$PROJECT_B


Publier les services dans le projet producteur
Publiez le service dans le projet B (le projet producteur) afin que les consommateurs d'autres réseaux VPC puissent s'y connecter en privé et y accéder en toute sécurité.

Réservez un sous-réseau pour Private Service Connect. La plage de ce sous-réseau ne doit pas chevaucher celle du réseau par défaut.

gcloud compute networks subnets create private-service-connect \
--network default \
--region us-west4 \
--range 10.0.1.0/24 \
--purpose=PRIVATE_SERVICE_CONNECT \
--project=$PROJECT_B

Publiez le service nginx auprès du projet A avec une approbation explicite.

gcloud compute service-attachments create nginx-service \
    --region=us-west4 \
    --producer-forwarding-rule=nginx-service-internal-fr  \
    --connection-preference=ACCEPT_MANUAL \
    --nat-subnets=private-service-connect \
    --consumer-accept-list=$PROJECT_A=10 \
    --project=$PROJECT_B
Vous pouvez contrôler la liste des consommateurs autorisés à accéder aux services publiés via une approbation automatique ou manuelle. Reportez-vous à Publier des services à l'aide de Private Service Connect.

Configurez une règle de pare-feu pour autoriser Private Service Connect à accéder aux instances cibles.

gcloud compute firewall-rules create allow-private-service-connect \
--direction=INGRESS \
--priority=1000 \
--network=default \
--action=ALLOW \
--rules=tcp:80 \
--source-ranges=10.0.1.0/24
--project=$PROJECT_B


Configurer l'endpoint dans le projet consommateur
Un endpoint dans le projet consommateur se connecte aux services du réseau VPC producteur via une forwarding rule Private Service Connect.
Lorsque vous créez un endpoint, il est automatiquement enregistré auprès de Service Directory, dans un namespace de votre choix ou dans le namespace par défaut, goog-psc-default.
Pour rendre l'endpoint accessible depuis plusieurs régions, activez l'accès global. L'accès global est en Preview.

Réservez une adresse IP interne à attribuer à l'endpoint.

gcloud compute addresses create private-service-connect-endpoint \
    --region=us-west4 \
    --subnet=default \
    --project=$PROJECT_A

Créez une forwarding rule pour relier l'endpoint au service attachment du projet B.

PSC_SERVICE_ATTACHMENT=$(gcloud compute service-attachments describe nginx-service \
   --region=us-west4 \
   --project=$PROJECT_B \
   --format="value(selfLink.scope(projects))")

gcloud compute forwarding-rules create nginx-service \
  --region=us-west4 \
  --network=default \
  --address=private-service-connect-endpoint \
  --target-service-attachment="projects/$PSC_SERVICE_ATTACHMENT" \
  --project=$PROJECT_A


Tester la connectivité depuis le projet consommateur
Les composants Private Service Connect sont désormais configurés dans les projets A et B. Utilisez l'IP de l'endpoint dans le projet A pour accéder au service nginx du projet B.
Le test confirme que les instances des réseaux superposés peuvent communiquer en privé via l'endpoint Private Service Connect.

Cet exemple illustre comment tirer parti de Private Service Connect pour publier et consommer en toute sécurité des services sur des réseaux superposés.
Le trafic reste intégralement au sein de Google Cloud, offrant un accès orienté service entre consommateurs et producteurs, avec un contrôle granulaire des modalités d'accès aux services.
Pour en savoir plus sur Private Service Connect, consultez la page produit.
\n'yum\ install\ epel-release


Créez un managed instance group dans le projet B.

Une fois la création réussie, le managed instance group lance une instance dans la zone cible.
Connectez-vous en SSH à l'instance et vérifiez l'état du service nginx.




Créez une instance de test de connectivité dans le projet A.


Les réseaux des projets A et B n'ont aucune connectivité interne. L'instance du projet A ne peut donc pas accéder au service exécuté dans le projet B.
Le VPC peering est impossible en raison du chevauchement des plages dans le réseau par défaut.
Mettre en place le load balancer interne
Un load balancer interne est nécessaire pour que Private Service Connect expose le service via un service attachment. Nous allons créer un load balancer TCP interne dans le projet B pour cette configuration.

Créez un nouveau health check HTTP régional pour tester la connectivité HTTP aux VM sur le port 80.


Créez le service backend pour le trafic HTTP.


Ajoutez l'instance group du service nginx au service backend.


Créez une forwarding rule pour le service backend.


Configurez une règle de pare-feu pour autoriser les health checks du load balancer.



Publier les services dans le projet producteur
Publiez le service dans le projet B (le projet producteur) afin que les consommateurs d'autres réseaux VPC puissent s'y connecter en privé et y accéder en toute sécurité.

Réservez un sous-réseau pour Private Service Connect. La plage de ce sous-réseau ne doit pas chevaucher celle du réseau par défaut.


Publiez le service nginx auprès du projet A avec une approbation explicite.

Vous pouvez contrôler la liste des consommateurs autorisés à accéder aux services publiés via une approbation automatique ou manuelle. Reportez-vous à Publier des services à l'aide de Private Service Connect.

Configurez une règle de pare-feu pour autoriser Private Service Connect à accéder aux instances cibles.



Configurer l'endpoint dans le projet consommateur
Un endpoint dans le projet consommateur se connecte aux services du réseau VPC producteur via une forwarding rule Private Service Connect.
Lorsque vous créez un endpoint, il est automatiquement enregistré auprès de Service Directory, dans un namespace de votre choix ou dans le namespace par défaut, goog-psc-default.
Pour rendre l'endpoint accessible depuis plusieurs régions, activez l'accès global. L'accès global est en Preview.

Réservez une adresse IP interne à attribuer à l'endpoint.


Créez une forwarding rule pour relier l'endpoint au service attachment du projet B.



Tester la connectivité depuis le projet consommateur
Les composants Private Service Connect sont désormais configurés dans les projets A et B. Utilisez l'IP de l'endpoint dans le projet A pour accéder au service nginx du projet B.
Le test confirme que les instances des réseaux superposés peuvent communiquer en privé via l'endpoint Private Service Connect.

Cet exemple illustre comment tirer parti de Private Service Connect pour publier et consommer en toute sécurité des services sur des réseaux superposés.
Le trafic reste intégralement au sein de Google Cloud, offrant un accès orienté service entre consommateurs et producteurs, avec un contrôle granulaire des modalités d'accès aux services.
Pour en savoir plus sur Private Service Connect, consultez la page produit.
\n'yum\ -y\ install\ nginx


Créez un managed instance group dans le projet B.

Une fois la création réussie, le managed instance group lance une instance dans la zone cible.
Connectez-vous en SSH à l'instance et vérifiez l'état du service nginx.




Créez une instance de test de connectivité dans le projet A.


Les réseaux des projets A et B n'ont aucune connectivité interne. L'instance du projet A ne peut donc pas accéder au service exécuté dans le projet B.
Le VPC peering est impossible en raison du chevauchement des plages dans le réseau par défaut.
Mettre en place le load balancer interne
Un load balancer interne est nécessaire pour que Private Service Connect expose le service via un service attachment. Nous allons créer un load balancer TCP interne dans le projet B pour cette configuration.

Créez un nouveau health check HTTP régional pour tester la connectivité HTTP aux VM sur le port 80.


Créez le service backend pour le trafic HTTP.


Ajoutez l'instance group du service nginx au service backend.


Créez une forwarding rule pour le service backend.


Configurez une règle de pare-feu pour autoriser les health checks du load balancer.



Publier les services dans le projet producteur
Publiez le service dans le projet B (le projet producteur) afin que les consommateurs d'autres réseaux VPC puissent s'y connecter en privé et y accéder en toute sécurité.

Réservez un sous-réseau pour Private Service Connect. La plage de ce sous-réseau ne doit pas chevaucher celle du réseau par défaut.


Publiez le service nginx auprès du projet A avec une approbation explicite.

Vous pouvez contrôler la liste des consommateurs autorisés à accéder aux services publiés via une approbation automatique ou manuelle. Reportez-vous à Publier des services à l'aide de Private Service Connect.

Configurez une règle de pare-feu pour autoriser Private Service Connect à accéder aux instances cibles.



Configurer l'endpoint dans le projet consommateur
Un endpoint dans le projet consommateur se connecte aux services du réseau VPC producteur via une forwarding rule Private Service Connect.
Lorsque vous créez un endpoint, il est automatiquement enregistré auprès de Service Directory, dans un namespace de votre choix ou dans le namespace par défaut, goog-psc-default.
Pour rendre l'endpoint accessible depuis plusieurs régions, activez l'accès global. L'accès global est en Preview.

Réservez une adresse IP interne à attribuer à l'endpoint.


Créez une forwarding rule pour relier l'endpoint au service attachment du projet B.



Tester la connectivité depuis le projet consommateur
Les composants Private Service Connect sont désormais configurés dans les projets A et B. Utilisez l'IP de l'endpoint dans le projet A pour accéder au service nginx du projet B.
Le test confirme que les instances des réseaux superposés peuvent communiquer en privé via l'endpoint Private Service Connect.

Cet exemple illustre comment tirer parti de Private Service Connect pour publier et consommer en toute sécurité des services sur des réseaux superposés.
Le trafic reste intégralement au sein de Google Cloud, offrant un accès orienté service entre consommateurs et producteurs, avec un contrôle granulaire des modalités d'accès aux services.
Pour en savoir plus sur Private Service Connect, consultez la page produit.
\n'systemctl\ start\ nginx \
--maintenance-policy=MIGRATE \
--provisioning-model=STANDARD \
--scopes=https://www.googleapis.com/auth/cloud-platform \
--create-disk=auto-delete=yes,boot=yes,device-name=nginx-service-instance-template,image=projects/centos-cloud/global/images/centos-7-v20230411,mode=rw,size=20,type=pd-balanced \
--no-shielded-secure-boot \
--shielded-vtpm \
--shielded-integrity-monitoring \
--reservation-affinity=any \
--project=$PROJECT_B